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that approximately '90% of the respondents reported some plans or 
actions toward developing an ILIS. A further discussion of survey 
results covers the areas of planning, justification, implementation, 
system data, hardware support, system funding, and the role of 
consultants in planning for an ILIS. A four-item bibliography and an 
evaluation sheet for this ARL Systems and Procedures Exchange Center 
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INTEGRATED LIBRARY INFORMATION SYSTEMS IN ARL LIBRARIES 



ISSN 0160 3574 

As liDrary automation has become more firmly entrenched, considerably more attention 
has been paid to developing systems that integrate the various library functions into one 
computerized system, rather than building standalone or single purpose systems that do 
not interact witn other functions. In October 1982, SPEC conducted a survey of selected 
ARL members to investigate the directions being taken in this area. For purposes of the 
survey, an integrated library information system (ILIS) was defined as including the 
following: 

(1) the four functions (acquisitions, cataloging maintenance, circulation, and the 
online catalog) rely on the same data without the need for rekeying, thus 

' creating a single functional database; 

(2) all functions are fully interactive with each other, with access to one fil6 (e.g. 
cataloging) leading directly through the same terminal to other functions kept 
automatically in sychronization; 

(3) the database is composed of bibliographic data (e.g., order records or cataloging 
records) as well as other data necessary to carry out library-related functions 
(e.g., vendor files for acquisition purposes, or borrower files for circulation). 

A cross section of 31 ARL libraries representing those that had well-publicized efforts in 
library automation and those whose plans were not as well-developed Or well-known took 
part in the survey. Approximately 90 percent indicated some plans or actions toward 
developing an ILIS. In general, the responses indicate that variations in ILIS 
implementation are occurring most frequently at the detailed procedural level, rather 
than at the policy level, with decisions focusing on the following areas. (More complete 
survey results can b^ found in the accompanying kit.) 

PLANNING AND JUSTIFICATION . Staff involvement in planning for the ILIS occurs 
most commonly through the establishment of committees. A majority of libraries have 
established committees to oversee the development of the ILIS, and these committees 
usually are separate from the regular administrative group in the library. Primary 
responsibility for the development and implementation of the system does not rest with 
the committee; rather it rests most commonly with the director of technical services 
and/or automation, the head of library systems, the director of libraries, or the director 
of administrative services. 

Libraries cited a variety of reasons to justify an ILIS, with a fairly even division between 
needs to improve technical processing and factors that most affect the public. Most 
frequently cited justifications were the increase in the amount of information that would 
be available to the public, the ability to provide distributed access to the bibliographic 
information, the improved access mechanisms (such as Boolean searching) that are 
possible- through a computer^ and-the increased staff- productivity that would resuU^ from 
simplifying the files to be accessed. 



The Systems and Procedures Exchange Center (SPEC) Is operated by the 
Association of Research Libraries, Office of Management Studies, 
1527 New Hampshire Avenue, NM, Washington, D.C. 20036, Telephone (202)232-8656. 



Of the factors that are seen to inhibit development of an ILIS, the greatest limitations are 
lack of funds and the nigh costs to develop and maintain the system. The lack of staff to 
perform the analysis, development and implementation also was found to be an inhibition, 

.and there is a concern that the problems presented in library automation are still too 

\idvanced for tiSe state-of-the-art. 

IMPLEMENTATION . For the four basic functions to be included in an integrated library 
system, no one method for implementation seems to predominate at^ this time. While 
turnkey systems and local implementation are the two methods most favored, the local 
implementation is continuing mainly in those libraries that* have had a substantial 
established efforts in the past. Libraries without such experience are opting primarily to 
go with library systems to mount locally. This trend holds with little variation based on 
the function to be automated. In this respect, binding control is the area where libraries 
have the greatest doubt how, or if, the function will be automated. Ttiere is still a 
significant sector of the surveyed libraries, however, that has not yet determined how 
implementation will be done, and a small number have no plans for an ILIS. 

Of those libraries that will be putting an ILIS into place, the trend clearly is to implement 
the system in phases, rather than to attempt to bring up all functions simultaneously. Of 
the functions to be implemented, greatest interest is in first implementing cataloging 
maintenance and circulation, and later the online catalog and acquisitions, 

SYSTEM DATA AND HARDWARE SUPPORT . To put an effective system into effect, 
most respondents believe that the system must contain the substantial (if not complete) 
portion of the library's collection in the database and prefer the inclusion of full 
bibliographic data. The greatest number 6i systems are, or intended to be, mounted onto 
dedicated library . computers. The minicomputer generally is seen as the hardware 
configuration choice. De'^icated ""library mainframe computers are also anticipated in 
some libraries, but microcv..nputers are not envisioned as having the capacity at this time 
to support an ILIS in an AR^ library. The use of a central campus computing facility, 
while not favored as heavily as the dedicated library computer, is still being (or to be) 
employed in approximately one-fifth of the responding libraries. 

SYSTEM FUNDING . In the majority of responses, the anticipated sources of funding are 
from the university. While development and maintenance costs are expected to come 
from the regular budget, hardware and software costs (whether developed locally, or 
purchased from another source) are expected to come more fr,om special allocations or 
outside grants or donations. 

THE R OLE OF CONSULTANTS . The surveyed libraries do not show a pronounced 
inclination to employ consultants in the planning for an ILIS. Over half the respondents 
are riot employing consultants in the ILIS development venture. Of those libraries that 
are, the greatest interest is in assistance with general decision-making, the analysis of 
specifications prepared by the library, hardware specification preparation, and 
implementation of the system. 

Kit //90 on Integrated Library Information Systems (January, 1983, 88 
pages) includes survey results, planning documents, general system 
descriptions and reviews, and examples of specfications. SPEC Kits are 
available mainly by subscription. Individual kits may be purchased when 
available for $15.00,' with checks made payable to "ARL Office of 
Management Studies." Ordering address is: SPEC Center, ARL/OMS, 1527 
New Hampshire Ave., N.W., Washington, D.C. 20036. Library members of 
ARL^receive SPEC kits for__$7. 50^ 

This flyer/kit was prepared as a p.art of the 
Collaborative Research/Writing Program by Arnold Hirshon, 
Assistant Head, Cataloging Department, Duke University. 
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USES OF SPEC KITS 



The Systems and Prcx:edures Exchange Center (SPEC) Is a 
cleorlnghouse operated by the Assoctatlon of Research 
Libraries. Office of Maragement Studies that provlc^es a central 
source of timely Infornnationand materials on the management 
arxj operatiore of large academic arid research libraries. It 
facilitates the exchange of knowledge and documents through 
SPEC Kits, which are distributed ten times each year to ARL 
members arxJ other interested libraries. The Kits include 
topically-arranged groupings of unedited primary source 
documents - selected for their value to adrpinlstrators and 
decisiorvmakers - that illustrate a wide range of alternative ap- 
proachies to specfc issues. 

Kit documents come from genejal membership surveys and 
from selected libraries contacted directly by SPEC, arxj most 
Kits are produced within six months of surveys. The documents' 
value comes from their variety of ideas, methods, and solutiore. 
They are not viewed as finished products, but rather as points of 
departure for a library s plannir^ efforts and as stimulants to irv 
rtovative approaches to problem-solving. As sucK Kits do not 
present ariswers or prescriptioris for any one library: instead 
they illustrate how selected ARL members are planning for or 
dealing with particular issues. The worth of any one Kit to a par- 
ticular library will depend upon the specific topic covered and 
the library's stage of development In that area. 



Materials are selected according to the following criteria: 

• Presents an approach of potential value to administrators 
and decision-makers'^ 

• fimely. and deoling directly with the topic under con- 
sideration 

• Probability of application of ideas or thinking to other 
library situations 

• Illustrative of actual practice, rather than theoretical 

• Understandable, readable communication 

All together, the riKiterials should provide a range of alternative 
approact^s that complement each other provide variety, and 
stimulate comparison and contrast. 

Libraries can take advantage of . ttie Kit compilations in a 
number of ways. Administrators con evaluate the assumptions. 
methKXjs. and results of other libraries' approaches; compare 
and contrast them a.xl use the learnings in their own situations. 
Library staff members can use the kits as professional develop- 
ment and current awareness tods. Committees and task forces 
can use them to begin a review of current practices. And the 
Kits can identify other persons or places to contact for further 
information Back-up files In the SPEC office also are available 
for loan to member libraries. In additioa SPEC will conduct on- 
demand surveys or analyses geared specifically for a single 
"library. 



EVALUATION 

Kit Title/Number — 

1. WNch uses did the library make of this Kit? 



2, Rease indicate how useful the Kit was for these purposes, 

□ Very Useful □ Quite Useful □ Somewhat UsefuJ □ Not Useful 

3. Do you tKive suggestions for this Kit or for future Kits? 



(optional) NAME _ 

LIBRARY 
PHONE _ 



Please return this form to the SPEC Center. OMS/ARL 1527 New Hampshire Ave.. N.W.. Washingtoa DC 20036 
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Timetable for Implementing an Integrated library system for the UTK Library 



The ultlmatl goal of the UTK Library Is the creation of an integrated 
library system (ILS). The conceptual as well as operational foundation of 
an ILS Is the existence of a computerized database of bibliographic records 
that can be directly accessed by all users from remote locations for a 
variety of purposes. An ILS Is made up of a number of modules providing 
the following services: acquisitions, fiscal xoonltorlng, serials and binding 
control, cataloging, access to the collections, and circulation and Inventory 
control. 

The process of creating an ILS consists of two major channels of activity. 

CONVERSION PROGRAMS 

A. Converting print bibliographic records Into computer-stored blblio- 
graphic records. This, In turn, has two segments: Monographic 
records and serial records. Work has been underway for some time 
on the retrospective conversion of monographic records. This will 
result In the computerized database of bibliographic records. 

B. Linking of faculty and student database records to create a library- 
user file. Associated with this Is the process of placing a bar 
code/OCR label on all faculty/student/staff Identification cards. 

C. Labelling of the library's collection with bar code/OCR labels and 
subsequent linking of Item Identification number with computer- 
stored bibliographic record. 

HARDWARE AND SOFTWARE DEVELOPMENT • 

This second activity entailsvthe preparation of the necessary specifi- 
cations, RFPs, evaluation of bids, negotiation of a contract, and installation 
of equipment and software. , This will be accomplished in four distinct phases: 

Phase I. Circulation and reserve system for Hosklns and Hodges; 

File maintenance and update for Automated Processing 

Phase II. Circulation for Ag/Vet Med and Music Libraries; 

Automation of Bindery and Interlibrary Services 

Phase III. On-line catalog and automated acquisitions 

Phase IV. Serials check-in and claiming control 



ERIC 



Hunt* to Norman 
Timetable. • • 



-2- 10/22/81 



The library is currently working on Phase I o'f the second activity, which is 
the acquisition of a mini-computer-based turn-key on-line circulation system. 
There is a degree of urgency in completing Phase I by May 1983, as the 
company that owns and services our Mohawk circulation equipment has informed , 
us that after this date they will no longer maintain ^the equipment. 

Following is the timetable for Phase I of the project and the projected 
timetables for the other three phases* 



STEP BRIEF DESCRIPTION 

" 1 Specifications ; 

t^rite detailed bid 
specifications 

2 Approvals ; 

V Obtain the internal 
approval of specifications 
(Purchasing, etc*) 

3 Bids: 



ESTIMATED TIME 



8 months 



Specs go out on bid 
Review; 

Review bids received; 
possible demonstration 
by vendor's 

Contract: 



1 iDonth. 



2 months 



1 month 



V 2 months 



6 months 



Award bid/contract 

Preparations; 
Install equipment, 
build files, debug, 
train, etc. 



Implementation and Evaluation; 3 months 
Acceptance tests, parallel runs 
remove Mohawk equipment in UGL 
and Main 

Begin Phase II 

TOTAL TIME NEEDED 23 months 



DATES 

June 1981-January 1982 
February 1982 

March-April 1982 
May 1982 

* June-July 1982 
August-January 1983 

February-April 1983 

May 1983— 

June 1981-May 1983 



Functions and Equipment Requirements 
for All Phases 

PHASE I 

Functions ; ^ 

1* Circulation control - Ma^n, Undergraduate Libraries 
2. Reserve control - Main, Undergraduate Libraries 

3 File maintenance and update - Main Library; Automated Processing Dept. 

" 0 ■ 
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Equipme.nt requlr.ements ; 

1 CPU - Minicomputer; ininiimun*256K core 

2 Disk drives - 300 megabyte storage preferred 
1 Printer - 300' lines per minute preferred 

1 Tape drive - 9 track, 1600 bpi preferred 
7 Terminals (CRT) ' / " 

6 Scanners (wands attached, to CRT/s) 
* 3 Modems and communication lines- 

PHASE II: May 1983-April 198A 

Functions: ^ 



1. Circulation control— Ag-Vet Med, Music Libraries 

Main: Binding aM Interlibrary Services Departments 

2. Reference Department access, all libraries 

3. Public access familiarity — Main, UGL 

Equipment requirements : 

\ 

16 Terminals (CRT) ^ 

1-2 Small printer —Binding and Interlibrary Services 

* 9 Modems and commi^aiiqation lines 

Phase III: May 1984-April 1985 
Functions t> T ' 

1, On-line catalog — all libraries 

2. 0i^dering, receivihg, .budget control for library materials 
Equipment requirements : 

29 Terminals (CRT) . \ 

* 18 Modems and conmunication lines 

Phase IV: May 1985-April 1986 « 
Functions: 

1. Serials check-in and claiming control 
Equipment requirements: 

1-3 Terminals (CRT) 

* 0-2 Modems and communication lines 



* Multiplepcors will, likely be used to combine up to 6 terminals on one 
communication line.* 
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Timetable... ^ ^ ' . ■ 

Concurrently'with Phases I and II, the conversion of bibliographic 
records will be occurring. The conversion of user records and the labelling 
of library materials must be essentially completed by May 1983, 

The library estimates that cost of implementing Phase I, excluding 
conversion costs, will be $300,000. Total cost of the ILS would be spread 
ov.er a 5-yeariperiod, Maintenance costs of l-lh^* of the hardware also needs 
to be anticipated,' 

Equipment Cost ^ 
Description ^ . Total System Cost 



1 CPU ■ 


$ 


103,000 


1 Tape Drive 




16,200 


A Disk Drive 




116,000 


(300 niegabyte) 






1 Printer 




7,600 


56 Terminals 




196,000 


(estimatea number) 




17,000 


1 Modem for Diagnostics 




A Pr. Line Drivers 




A, 000 


Installation, Cables, etc., (estimate) 




15,000 


Software (estimate) 




50,000 




$ 


52A,800 



The cost of other modules in the ILS is open to considerable speculation 
because all turnkey vendors are in the development and test stages. A cost 
of at least $25,000 per module improbably a conservative estimate at this 
•time. 



Sincerely 



Donald R. Hunt 
Library Director 



DRHrpw 
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EXECUTIVE SUMMARY 



I. INTRODUCTION 

As the collections, user populations and demands for library services at 
Duke University have grown, the management of bibliographic information has 
become more complex. At Duke Univers.ity, the application of dat|^ processing 
techniques to improve operations has been implemented in a patchwork fashion. 
As a result.^ the automated systems currently in use are leased on different 
techniques and there is no linkage among the various functions. The present 
study, which employed the Application Transfer Team (ATT) methodology de- 
veloped by IBM, was to define "a model system to be used in making future 
decisions concerning 1 ibrary automatio; . 

The length of bibliographic and related records, the unique identifica- 
tion and detailed description of each physical piece in the 1 ibrary col lec- 
tion and the need to exchange bibliographic informatiori, both within the 
university as well as with libraries outside, make a library system particu- 
larly complex to implement.' 

The scope of this study was to develop a conceptual design for an 
integrated system based upon bibliographic information to ensure the effec- 
tiveness of library services at Duke. This design establishes what an 
information system should provide, not how th'at system should be implemented. 
The sudy will be used as a model agaTnst which possible implementation 
•strategies should beyneasured and evaluated. 

The study had five specific objectives: (1) to develop an understanding 
of the current environment and information needs of the libraries; (2) to 
define the functions to be supported by the system; (3) to promote coopera- 
tion, including the sharing of data (as appropriate) given the constraints of 
the various constituent library organizations.; (4) to assess the need for 
changes to the organizational' structures that might be necessary for effec- 
tive implementation of the integrated system.; an'd (5) to determine priorit.es 
for implementation of the various system component:. : 

From interviews that were conducted with students," faculty and library 
staff, it was concluded that there were three functional areas from which the 
system design should grow: processing control, bibliographic control and 
access, and col Section, control . These are defined more fully in section V 
below. 



II. CURRENT LOCAL ENVIRONMENT 



The Duke University Libraries are administratively divided into three 
systems: the Medical Center Library, the School of Law Library, and the 
Perkins Library system, whir.h is the largest and is composed of the William 
R. Perkins Library -and its nine branches. The collections of the three 
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systems total more than 3,000,000 volumes and the union catalog in Perkins 
alone holds over eight million cards, with 6,550 added each week. The 
circulation count of all the libraries nears 393,000 items each year, plus 
17,700 interlibrary loan- transactions. 

Computer technology is used at presertt to help order, process and 
retrieve materials. The Technica.1 Services Data Base (TSDB) is used as an 
acquisitions/in-process file to* procure and track the progress of material . ^ 
In 1980, plans were announced for the Medical and law School libraries to 
join Perkins in using this system and for the system to be made available at 
public service points. 

Access to serials holdings is provided via computer output microform 
(COM) catalogs, with brief bibliographic information and summary holdings for 
cataloged serials in Perkins and Law in one list, and a separate iist for the 
Medical Center Library. 

In late 1978, the Perkins and Law Libraries began to use the Online 
Computer Library Center (OCLC) system for online cataloging via a membership 
in' the So'utheastern Library Network (SOLINET). 

The Triangle Research Libraries Network (TRLN) is a cooperative rela- 
tionship among the three research libraries in the Triangle area: Duke, the 
University of North Carolina at Chapel Hill (UNC-CH), and North Carolina 
State University (NCSU). Through continuing funding provided by a Higher 
Education Act Title II-C grant, work has begun on the development of a 
comouter and telecommunications-based bibliographic system to link the three 
institutions'. This system is explained further in section III below. 

A particular frustration for the Duke libraries has been the unaccept- 
able performance by the Triangle Universities Computation Center (TUCC), 
which supports the TSDB. Downtime has been of unprecendented length, 
and response time has been poor. This performance led to the identifi- 
cation of high availability and reliability as requirements for a future 
system. 

Through the interviews conducted by the Team, six issues and concerns 
were identified concerning the present systems: (1) the la k of unyied 
records produces an unwieldy system in which it is difficult or impossible to 
update information consistently, to track material, and to produce necessary 
outputs; (2) the use of many manual files has created labor intensive 
operations and much data redundancy; (3) access to present automated systems 
is inadequate and when provided, systems are often unreliable and inadequate 
to meet our needs; (4) cooperation among departments aqd libraries, and witn 
other organizations, is difficult because of logistical problems such as 
access to data; (5) current docxjmentation of procedures and systems is not 
available, thus creating problems of usability of the library for patrons and 
staff; (6) there are unrealistic expectations of what autoiigated systems can, 
will , and should do. 



13 

6 

i i 



III. NETWORK ENVIRONMENT 



The current network environment can be characterized as unstable. 
At present, SOLINET does not directly provide computerized services, but acts 
as a broker of OCLC services. In the near future, OCLC and SOLINET may 
enter into a joint venture to provide shared automated services, but the 
effect of these plans on local planning is questionable. 

SOLINET, using the Washington Library Network (WLN) software, originally 
planned to develop a regional support system, for the updating of local 
libraries OCLC-MARC Subscription Service (archive) tapes of cataloging 
records. Recently this concept has changed from catalog maintenance to 
providing a "reference subsystem." The effect of this decision is as yet 
undetermined. SOLINET has also announced increases in their charges. 

The TRLN project is based on a report of two consultants, John Knapp and 
Ritvars Bregzis, "that a computer and telecommunications-based bibliographic 
system should be established in each of the Triangle University Libraries as 
the core of a bibliographic access network. ..[to] consist of three minicom- 
puter sytems, one located at each library, linked by telecommunications 
facilities, using identical operating systems and telecommunications soft- 
ware, and compatible applications software." The project has been funded 
under the HEA Title II-C program and recently it was announced that^the grarn 
has been renewed for one^ year , with good prospects for funding to complete 
the three year project goals . 

Since the TRLN project began, the following has already been accom- 
plished: (1) compatible standards for representing monographic .holdings have 
been adopted by all three institutions; (2) an archive tape processing system 
has been put into effect, providing a means to merge archive tapes into 
separate master databases for each institution, and computer validation of 
records to ensure data consistency; (3) a COM catalog has been produced for 
all three institutions; (4) the specifications have been completed and 
operation should begin late this fall of an online system for update and 
•maintenance of archive tapes. The archive tapes will be the basis for the 
online catalog. 

Involvement of Duke staff in the ongoing development of the project has 
been high, and there has been no issue to date that has not met with con- 
sensus. , 

Future plans for the TRLN project include: (1) in the next grant year 
(October, 1981 -October , 1982) the design of the bibliographic and holdings 
modules will be completed and maintenance of these will be operational. 
Access to records via record key (e.g., OCLC record number) and other stand- 
ard access methods will be designed; (2) by the end of the 1983 period, 
maintenance of the authority module will be implemented and links between 
authority and bibliographic modules established, and standard access methods 
(author, title, subject, call number, i.e., similar to the traditional card 
catalog access) will be in operation; (3) the third year (1984) will bring 
completion of the bibliographic access project, with the availability of 
sophisticated search strategies such as Boolean (and/or, not) operators and 
keyword searches, as well as instructional programs and system prompts. 

7 



The primary impetus for TRLN was the recognized need to avoid redundant 
development of in-depth research collections. Detailed coordination of 
collection development relies on full bibliographic access to each collec- 
tion. While it may be faster or easier to develop a bibliographic control 
and access system at Duke, it seems unlikely that any local effort could be 
completed at this time faster then TRLN. Even if faster, considering the 
funding by HEA Title II-C, local development would be more expensive to the 
university. Given the high level of satisfaction in the Duke Libraries with 
cooperative ventures in the past, it would be unfortunate if that cooperation 
were not continued through Duke*s participation as a full partner in the TRLN 
project. 

It is recommended that the core of the integrated library system at Duke 
be the TRLN bibliographic control system and that the processing control and 
collection control functions be implemented so they are fully, efficiently 
and effectively compatible with all aspects of the TRLN system. The possi- 
bility of joint TRLN development of the other system components should be 
explored. 



IV. CHARACTERISTICS OF THE DESIRED SYSTEM 

A computer system should help increase the speed, accuracy, and produc- 
tivity of library staff, and provide relief from most of the repetitive, 
labor intensive operations. 

Hardware related characteristics include online terminals, with the 
capability to support at least 200 terminals. Since the environment dictates 
more online tranactions than batch, and more transactions for search and 
display than for maintenance of data, there must be good response time 
(average of three seconds, and a maximum of six seconds). Entensive data 
storage and processing capacities are required as well as expansion capabil- 
ity without major hardware replacement. The hardware must be extremely 
reliable (no more than two percent failure) and there must be backup systems 
(either hardware or output supplied). The system must be available during 
all hours of the libraries' operations, and dial access must be accommodated. 

Software related characteristics include basing the system on the full 
MAchine Readable Cataloging (MARC) standard format for bibliographic and 
authority records and other standards where available. The system must be 
integrated, with all functions sharing a central database of bibliographic, 
processing and holdings Information and access to accounting, requestor, 
supplier and borrower information. 

The system should increase accuracy and timeliness of information and 
eliminate redundant maintenance of files. It must include the ability to 
produce forms, labels and management reports on demand. The system should 
allow only one person at a time to update a particular record and have the 
capability to perform format recognition and automatic validation of records. 
Date security must be provided, including the generation of machine readable 
daily logs (transaction audits), authorization for creation and maintenance 
of data, and monitoring of terminals to prevent unauthorized users from 
performing restricted transactions. 



The system should be flexible, capable of modification and expansion 
without major system redesign, and should require minimal programming main- 
tenance. 

The system should have powerful search capabilities, such as keyword and 
Boolean operators. There should be direct user access to information on the 
availability of items from time of order thfough circulation, and the system 
must be easily employed by users with varying levels of expertise. This 
requires self-tutorial modules, system prompts, and system translation of 
encoded data into text before displaying on screens and reports. 

The system must be capable of interfacing with other automated systems, 
whether local, regional or national, including the university accounting 
system, the In-School system, faculty and staff payroll files, the Bursar 
files, the TRLN bibliographic control and access system, and SOLINET and 
OCLC. 

V. SYSTEM DESIGN 

The system is comprised of three subsystems: processing control, 
bibliographic control and access, and collection control. The system 
is designed according to the functions to be performed and not accord- 
ing to departments in the libraries. 

The structure and content of the various databases and files in the 
system will be determined ultimately by the type of database management 
system selected. Since the selection of a management system will not be 
accomplished until the make-or-buy decision that follows this study, ATT did 
not identify the databases or files. Instead, data elements were organized 
into logical categories and interrelationships of data elements were noted. 
These data categories include information in the following areas: biblio- 
graphic, holdings, processing, requestor, supplier, fund, system control, 
authority control, charge-out/return, recall/hold, reserve, borrower, and 
inter library transactions. 

Processing Control consists of all functions related to the procurement 
and control ot library' materials prior to full cataloging. The system must 
handle all types and formats of materials (e.g., books, journals, non-book 
publications, etc.). 
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When a full bibliographic/authority/holdings record has been created 
through the bibliographic control function, the processing record wilKbe 
purged. For materials that never" receive full cataloging (e.g., govern#it 
documents), the minimal bibliographic information in the processing record 
.will become the permanent record in the system. 

Bibliographic Control and Access provides a mechanism for the creation 
and maintenance of, and access to, bibliographic and holdings information. 
Three component records are generated through this function: bibliographic, 
authority, and holdings. 

The bibTiographic record includes a description of the work, analysis of 
the subject content, and access points to the work (such as the author, 
title, or subject headings). 
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The access points for the fully processed records have the heading forms 
controlled through an authority file. The authority file ensures that each 
heading is entered into the system in a uniform manner, and that alternative 
forms of the headings are given as references to the correct form. 

Holdings records include piece specific information concerning the 
work: library location, call number, copy and volume numbers of each physical 
piece, piece specific notes and special features information, and machine 
readable identification number (e.g., bar code). 

The access and reporting function provides a method for retrieving fully 
cataloged records (if available) or processing records (if fully cataloged 
records are not available). Access will be provided using a variety of entry 
points, including author, title, series, subject, and keyword searching. 
Output, such as specialized bibliographies or statistical reports, could be 
provided either online or batch. 

Collection Control includes two major subf unctional areas: physical 
control, and the handling of interlibrary transactions. Physical control is 
a means for keeping track of fully processed material that is not in its 
permanent location (e.g., material is out on loan or is lost or missing)* 
Interlibrary transactions includes a mechanism to receive and verify requests 
for materials from Duke users and from other libraries, and electronic 
transmission of procurement and lending transactions. 

VL IMPLEMENTATION 

The ATT charge did not allow for a review of automated library systems 
and pack'ages now available. While the, estimates for costs were based on 
development and implementation at Duke, this report does not endorse or 
reject any set of techniques or any specific hardware. It does stress and 
recommend in the strongest terms that whatever software and hardware is 
selected, the highest consideration be given to the needs of the Duke li- 
braries, local participation in TRLN, and Duke's dependence on national 
utilities such as OCLC. 

The team developed an implementation strategy that took into considera- 
tion the logical requirements of building interdependent parts of the system, 
the early direct benefits to library users, and the present circumstances of 
the current local environment. The team recommends that the processing 
control and collection control subsystems be implemented together in two 
phases over a 24 month period. Section VI of the full report describes the 
tasks to be accomplished in each phase. The bibliographic control and access 
subsystem is to be developed through the TRLN project. This would be done 
concurrently with the development of processing and collection control. The 
schedule for TRLN development is outlined in Section III of the report. 

There are problems that delaying implementation would exacerbate. 
Obviously, the maintenance of a labor intensive operation, fraught with 
duplicative efforts, would continue during the delay period. Of greater 
concern is the status of the present systems. The TSDB cannot perform many 
of the necessary functions that have been identified, such as automatic 
claiming, sorting of orders by vendor, producing management reports on 
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demand, or allowing for efficient reordering of multiple copies. Further, 
the TSDB represents yesterday's technology. At present most systems are 
expected to have a lifespan of five to ten years; the limitations of the TSDB 
are amply illustrated by the use of fixed length fields for variable length 
data"-a technique that no longer needs to be employed for efficient database 
management. Reprogramming to make the TSDB do more of the functions required 
by the library would not be cost effective considering the limitations 
inherent in the design. 



Another cost of delay would be continued reliance on the^ services 
of TUCC, services that have proven ineffective for administrative data 
processing. Moving the TSDB from TUCC to DUCC would not meet library 
needs because the system itself has been judged inadequate. 

Delay in implementation would bring no relief to areas that are in 
need, particularly serials control. Many operations would continue to 
be performed manually, if at all, and work would be highly redundant. 
This ultimately would be reflected in problems in collection development and 
management and in user services. Reliance on the existing manual circulation 
system would cause continuing problems for the user, such as the difficult 
process that must be used to check-out and renew books, and the manual 
generation of overdue notices. 



VII. COST-BENEFIT ANALYSIS OF THE PROPOSED SYSTEM 



The actual costs of the projected system are enumerated in full in the 
report (section VII). Since this information is in tabular form and is not 
amenable to summarization, no precise cost figures are included here. 

Three kinds of costs were calculated: development, operating and 
equipment costs. Development costs for the processing and collection control 
subsystems are more detailed for phase I than for phase II and include 
estimates for database design, documentation, and development of searching 
and training modules. Development costs for the bibliographic control and 
access subsystem reflect costs for in-house development. Should the TRLN 
project be used for the bibliographic component of Duke*s library system, as 
recommended, development costs would be replaced by the as yet unknown costs 
of developing an interface. 

Operating costs were derived by multiplying the number of current 
transactions times $0.10 per transaction (DUCC costs). Should the library 
lease or purchase a library-based computer, these transaction costs would be 
replaced by hardware costs. Operating costs for DULIS will rise when the 
entire system is operational (including bibliographic control and access) 
since this is when the public will make fullest use of the system. 

Equipment and equipment costs were based on an estimate of the number of 
new terminals, printers and control units heeded in addition to those already 
in the Mbrary. Because of the fully interactive nature of the system and 
high staff reliance upon it, terminals were projected on the basis of one 
terminal for -every two technical processing staff members, two terminals for 
every branch library, and, using a common library rule of thumb, one terminal 
for every one hundred public users. Costs are based on current IBM leasing 
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rates. It is estimated that 10% of the total system costs would be distri- 
buted to the School of Law Library and 15% to the Medical Center Library, 



Benefits derived from such a system were separated into two categories: 
dollar benefits and intangibles. Dollar benefits were calculated by dividing 
the total number of task transactions per year in each functional area by the 
rate of transactions per hour. This was multiplied by the average salary per 
hour (including benefits, but without inflation). Tasks that were not 
necessary under the automated system, or which would be accompl ished more 
quickly, were omitted or adjusted. 

There are eight additional benefits that were not quantified but that 
nevertheless result in direct benefit to the University, These intangible 
benefits are (1) union access to bibliographic data in all campus libraries 
for library staff and users, including access t:o materials on-order, in- 
process, or in circulation; (2) shared collection development among campus 
libraries and among Triangle libraries would be enhanced due to better access 
to information; (3) improved quality of data in that, it would be more timely, 
accurate, and secure; (4) more effective use of University resources, such as 
electronic interfacing with other University systems (accounting, student 
tracking, etc); (5) improved service to public users provided by union 
access to bibliographic data from non-library building locations, more 
information concerning the location and status of items, more flexible search 
capabilities, and improved quality of data; (6) improved management data and 
reporting, leading to better planning and budgetary control; (7) a more 
understandable system, easier to use, with self-instruction modules and 
comprehensive documentation; and (8) improved image of the University and the 
libraries by meeting library service expectations of prospective students, 
faculty^ and staff. 
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RECOMMENDATIONS 



A. Participation and Funding 

•1. An Duke libraries should participate i.n the development and use of 
the system, and should accept standardized data control • 

2. The project should be budgeted as a whole. The full benefits will 
accrue from an integrated system only if the entire system is 

- operational. The "stand-^alone" system approach that is reflected 
in the existing library systems at Duke leads to redundant data and 
requires labor intensive operations to manipul ate incompatible 
automated systems. 

B. Management of Implementation 

1. The library administrations should establish a library automation 
committee composed of staff from the Perkins, Law and Medical 
libraries. With the approval of the library administrations, this 
committee should: 

(a) make decisions concerning the policies, practices, and organi- 
zational matters related to library automation projects 

(b) coordinate activities of the project's data processing 
implementation team (explained in further detail below) 

(c) coordinate the various Duke-related activities of the TRLN 
project. 

Members of the committee should have in-depth knowledge of a 
library operation and of automated systems, as well as general 
knowledge of the library organization. For the sake of continuity 
and familiarity with this system design, members of the current ATT 
study team should initially serve on the automation committee, with 
the length of service and other membership to be determined by the 
1 ibraries* administrations. 

2. An implementation team should be established ^ts soon as possible. 
This implementation team should be chaired by a project manager who 
would report to the library automation committee. The membership of 
the team should consist of the appropriate data processing staff 
and of various library staff members (2-5) to represent the library 
functions being implemented. The library staff representatives may 
change as the functions to be implemented change. 

C. Implementation Plan - General 

1. The implementation of the system should take place in phases (as 
described in the full report) and the system functions should be 
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implemented in the sequence identified in the report (unless 
otherwise indicated after the alternative methods of implementa- 
tion, as described below, have been investigated.) 

2. An evaluation of alternative methods of implementation, particu- 
larly concerning processing and collection control, should be 
undertaken. This evaluation must include all requirements ^numer- 
ated in this study, particularly in terms of the recommendatf;j;ohs in 
item D below. The study must also include an assessment of dedi- 
cated library hardware versus utilization of a campus computing 
facility. Members of the present ATT study team should be involved 
in this evaluation for purposes of continuity and because of their 
familiarity with the requirements of the library system. 

Implementation Plan - Bibliographic Control and Access and TRLN 

1. The bibliographic control and access system being developed by TRLN 
should be used as the bibliographic component of the Duke library 
system. All other system development (described in item E' below) 
must be full^ and economically compatible with the TRLN system in 
terms of hardware, software, and operational and database manage-, 
rient systems. 

2. Cooperative development of the processing and collection control 
subsystems should be investigated with the other TRLN members to 
help ensure maximum compatibility of those subsystems with the 
bibliographic control and access system. 

Implementation PUn - Processing Control and Collection Control 

1. The implementation of the processing and collection control sub- 
systems should be done using the most current and cost effective 
data processing technology available (e.g., use of database manage- 
ment techniques.) 

2. An evaluation should be made of techniques currently available for 
capturing OCLC record data online to load into a local system. 
Data capture should occur as early as possible in the process. 

Training 

1. The personnel hireu i-o implement the system should either have 
knowledge of or be trained in the technical specifications, comput- 
er' languages and the database management system to be employed 
before embarking on the project. 

2. Adequate initial and continuing training should be provided in the 
use of the system once it is available. 




14 



GENERAL SYSTEM DESCRIPTIONS AND REVIEWS 



\ 



22 . 



ERIC 



UNIVERSITY OF CALIFORNIA AT BERKELEY 



AUTOMATION OVERVIEW 



RLIN/OCLC 
, (Shared Cjitsloging) 




TALUS / \ MELVYL 

(Library Processing) (Public Access) 



'^3 



ERIC 



15 



U.C. BERKELEY 
Page 2 



The Goal 



Automated systems in the UC Berkeley Library have evolved to a 
point where both library patrons and processing staff are involved in ' 
their use. Patron use of automated syste^ns to access Library holdings 
is increasing. Processing staff provide the records for public access 
through almost exclusive reliance on automated procedures. The 
interface of all automated components must be carefully designed to 
create an integrated library system. The current goal of automation 
plamiing is to create a processing flow that links Berkeley's use of 
three major computerized components. These components are: 

1) RLIN/OCLC (bibliographic utilities) for use as a source 
of fully cataloged records inc>the LC MARC formats 

2) MELVYL for use as the University-wide 01:1- line catalog 
for public service acce^r^ 

3) TALUS for use as the Library processing system 



RLIN/OCLC * 

The cataloging utilities (RLIN/OCLC) are a sour^e,^ shared 
cataloging copy. Neither MELVYL nor TALUS has this resource feature 
at present so the use of RLIN/OCLC will continue. Machine-readable 
cataloging records will continue to be received from these 
bibliographic utilities and will be added to our local databases for 
public access (MELVYL) and library processing (TALUS). 



MELVYL 



MELVYL, \he on-line Catalog for the nine University campuses, 
displays bibliographic records created on RLIN/CCLC and local campus 
systems. Currently, only a prototype version uf the MELVYL system is 
available. This prototype contains randomly selected, fully cataloged 
campus records from RLIN/OCLC in the MARC Books format. MELVYL, which 
is under development by staff at the System-wide Division of Library 
Automation (DLA), will include all the machine-readable Books records 
the cam|>uses have created, but records now in the prototype database 
are static. Any maintenance that may have been done to any of the 
prototype records by the owning campus is not reflected in the MELVYL 
database. Vhen the DLA %pdateable database" is available, changes 
made to records will be sent to DLA along with new campus records and 
loaded into the MELVYL database on a regular basis. 

Eventually, MELVYL will Include the other MARC formats. Work is 
currently tmderway to investigate loading the CALLS (California 
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Academic Libraries List of Serials) database- CALLS records are brief 
and do not contain ouch of the information called for in the MA^C 
Serials Forwat, but the load of this database will provide on-line 
fccces-j to University serials holdings using a modified version of the 
MELVYL search capabilities- Work on the other MARC formats (Maps, 
Music, and Films) will follow. 



TALUS 



TALUS, the Berkeley Library processing system, will be used to 
maintain the records cataloged on RLIN/OCLC and displayed in MELVYL. 
TALUS will complement, not duplicate, the MELVYL on-line catalog by 
providing staff with on-line management of machine readable records. 

A Tandem computer and terminals will be used to run and access 
TALUS. The main computers are now housed at University Hall in the 
Systemwide Division of Library Automation (DLA) . ^The Tandem terminals 
used to access the system will be located initially in central 
technical processing areas- Microfiche catalogs will continue to be 
produced for public service and central processing access- It will 
be possible to access both the MELVYL arid TALUS databases from a 
single, TALUS terminal- 

TALUS will be phased into production in the following stages: 

Phase I: Query and Maintenance maintenance of bibliographic 
fields (including call numbers and holdings) only, not 
processing fields such as vendor or fund. The 
Data^oint will still be used for acquisitions work. 
^ ' TALU§f tapes will be interfaced with the current local 

database-* The TALUS tapes will look like another 
RLIN/OCLC-type bibliographic utility to the local 
system. 

Phase II: Acquisitions Processing Books and Serials (all 

library materials) (including fund accounting). The 
Datapoint will be gone- ^ 

Phase III: Inventory Control 

Phase IV: Serials Processing check-in, claiming and binding 
information 



THE TALUS DATABASE 



TALUS will contain bibliographic records stored in the standard 
MARC formats for Books ^ Serials and Haps. The possibility of loading 
records in the Scores, Sound Recordings and Films (Audio/Visual) 
formats is being investigated- The TALUS database will store MARC 
tags without renaming them to UCB local values and will retain 
indicators and delimiters. In other words, we will use the standard 
MARC formats rather than the modified MARC used in the Datapoint- 
based system- This feature will make processing work a great deal 
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more consistent. Records that are now in the local database will be 
loaded into TALUS. The current local database includes fully 
cataloged records from RLIN/OCLC and all TCP, local cataloging, and in 
process/on order records keyed on the Datapoint. Local database 
records are in the Books, Serials ^and Maps forvnats. The loading of 
our current database into TALUS is complicated by two factors that 
Involve local keying practices as well as the programs used to 
interface RLIN/OCLC 0c^7ids: 

1) Standard MARC tags are not used in the current local 
database. Tags have been used that jo not exist or are used for 
other purposes in the standard MARo format. A program is now being 
written that will translate these local tag names to their standard 
counterparts . 

2) The local system does not store subfield delimiters. ^For 
most tags there is no way that these can be added or replaced through 
programming because cataloging practices have varied so much over the 
years. Archival RLIN/OCLC tapes will be used, when possible, to 
correct this problem, but the majority of uncataloged recofds will 
not contain subfielding after the? TALUS load, 

Aftei all existing Berkeley bibliographic records have been 
loaded into TALUS, new RLIN/OCLC tapes will be interfaced directly 
into the TALUS database. TALUS tapes will then -be used to supply 
the cataloging information used in the production of the microfiche 
catalogs (CAT 2). 

The CU Authority File (CUAF) will continue to be keyed and 
maintained on the Datapoint. It is not yet .clear how authority 
control will be handled in TALUS. The Headings File (discussed 
below) will be used initially for this purpose. In part, decisions 
about authority control in TALUS will be based on developments in 
MELVYL. If DLA is ab-le to load the full LC MARC authority tapes into 
MELVYL, TALUS will probably link to that information. If MELVYL will 
not contain the LC authority tapes and the records in the CUAF , then 
TALUS will need to include an authority contrbl system. 



TALUS — PHASE I: QUERY AND MAINTENANCE 



For Phase I, records will be loaded into TALUS in three batches. 
The projected o^der is: 
1. OCLC records 

*2. TCP, TAGS, Ictcal cataloging records 
3. RLIN records 

OCLC was chosen for the first loading because maintenance of OCLC 
records must be done locally; theDCLC system does not support 
maintenance of records in its database. TCP, TACS, and local catalog 
records must also be locally maintained. RLIN records will be loaded 
last if RLIN maintenance is available. This order may change 
depending on the performance of the RLIN system. 

■-^6 
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During Phase I, LC MARC bibliographic fields (including call 
numbers and holdings) will be maintained on TALUS, and our local 
processing fields will be maintained on the Datapoint. When Phase I 
has been completed and the Acquisitions Processing functions of Phase 
II are available, maintenance on all types of on-line records will be 
done on TALUS. When Phase II is in operation, a single Newsys 
record will include bibliographic and holdings information as well as 
in process and on order information. 



SYSTEM OVERVIEW 
FILE DESIGN 



TALUS stores information in four files. The separate file 
structure is invisible to the TALUS terminal operator. 

1. HEADINGS FILE 

2. BIBFILE 

3. HOLDINGS FILE 

4. ASSOCIATED INDEXES 

1. The HEADINGS FILE stores all personal, corporate/ confe^^ence, 
uniform title, topical subject, and geographical subject headings that 
are found in bibliographic records. If we decide that the futtire 
authority file belongs in TALUS rather than MELVYL, authority records 
will replace records in the HEADINGS FILE. The HEADINGS FILE is 
interactive and headings records are accessible for modification. All 
bibliographic records that use a particular heading will be linked to 
the appropriate heading record. When the HEADINGS FILE record is 
modified, the system will automatically change headings in all linked 
bibliographic records. Thus, bibliographic changes that must now be 
keyed repeatedly for each occurrence of a heading will, on TALUS, need 
to be keyed only once. To link headings, TALUS stores the 
bibliographic. Tandem-assigned record numbers in the HEADINGS FILE and 
the corresponding HEADINGS FILE numbers for each heading in the 
bibliographic record. 

2. Bibliographic records are stored with full MARC tagging in 
the BIBFILE. The headings for these records are also stored in the 
HEADINGS file. The links between the BIBFILE and the HEADINGS file 
are automatically created when the record is input or loaded into 
TALUS as described above. 

3. Holdings (call number, location(?), summary and/or detailed 
holdings, etc.) are stored in the HOLDINGS file. 

4. The ASSOCIATED INDEXES sort and normalize information for 
storage. These indexes are the avenues through which TALUS accesses 
the information stored in its database. Information is added to the 
ASSOCIATED INDEXES automatically as each bibliographic record enters 
the TALUS database. Each index stores only specific portions of the 
bibliographic record (for example, the call number index stores only 
the call number from a record along with Jthe TALUS record number 
link back to the bibliographic record to ^hich it belongs). When 
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searches are performed on TALUS, it is the ASSOCIATED INDEXES that 
are actually being searched. The summary screen that results from a 
TALUS search is a display of the normalized ASSOCIATED INDEX for that 
file. For example, a title summary screen results from a title search 
and displays the normalized title -stored in the ASSOCIATED TITLE 
INDEX. After the appropriate bibliographic record is found on the 
summary screen, that record can then be displayed In a detailed, 
unnormalized screen. It is this detailed display that reflects the 
actual storage of bibliographic fields on TALUS. Only the ASSOCIATED 
INDEXES are built with normalized information. 

Each search on TALUS accesses its own associated index and 
results in a different display. Searches and ASSOCIATED INDEXES are: 

**Title 

**Call Number 

^Record Number 

RLIN " OCLC - UCB (Datapoint) - LCCN - ISSN - ISBN - Tandem 

**Headings 

Personal Name 
Corporate/Conference Name 
Uniform Title 
Topical Subject 
Geographical Subject 
Normalization is the process by which the TALUS system standardizes 
bibliographic information for index storage and retrieval. Only 
the Associated Index files store information in the normalized form. 
The actual fields as input are stored in the HEADINGS FILE, BIBFILE 
and HOLDINGS FILE as input without being normalized. Although it 
varies somewhat from index to index, normalization involves: 

**Converting all alphabetic characters to upper case 

**Removing initial articles 

*T^Changing punctuation, diacritics and some special characters 
to blanks 

**CoHapsing multiple blanks to a single blank 
The special characters that are translated rather than changed are: 
Polish L/1 
Turkish i 

Digraphs AE/ae and OE/oe 
Swedish crossed O/o 
Hooked O/o and U/u 

Icelandic Thorn (upper/lower) translated to TH/th 
Eth — translated to th 
Script 1 

The following searches will initially be available on TALUS: 

1. The TITLE search index accepts searches up to 50 characters 
in length. Title searches must begin with the first word ofr the title 
that is not an article. If only the first portion of the title is 
known, the user inputs what is known. The system assumes that all 
searches have been truncated and expands each one automatically. 
Title summary screens display normalized titles with up to ten records 
listed on a single title summary screen. If more than ten records are 
retrieved the keyer then scrolls forward through the undisplayed 
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records. Once the keyer proceeds from the first title summary screen > 
it is also possible to scroll backwards through a limited number of 
titles already displayed, It will be possible to specif iy the MARC 
format (i.e. Books, Serials, Maps, etc.) in conjunction with the title 
search. The title summary screen display includes the the publication 
date and the normalized title. 

2. CALL NUMBER searches are up to 100 characters in length. The 
call number is also normalized for retrieval and display. For call 
number normalization all prefixes (f, ff, t, etc.) are stripped. 
Normalized call numbers display on a call number summary screen. A 
reversed scrolling function. is available. When the call number search 
result is first displayed the keyer may scroll back through screens 
that list call numbers falling before the one used as a search key, 

3. A RECORD NUMBER search is done using any of the numbers listed 
above. Because this search is record-specific it retrieves only a 
single record and displays it in a "detailed format". The detailed 
display includes the full MARC record in combination with local call 
numbers, RLIN/OCLC/Datapoint numbers, and any local notes. Although 
the headings, all numbers and holdings are actually stored in separate 
files, all fields are combined in the detailed display and the fact 

of separate storage is not apparent to the user. 

4. The HEADING search differs from the searches discussed so far 
because of the way in which the ASSOCIATED HEADING INDEX is built. In 
this index, headings are stored only once, regardless of the number of 
bibliographic records in which they are used. Once a record for a 
particular heading exists in the HEADINGS file, each subsequent use of 
the heading in a bibliogiaphic record is automatically linked to that 
Heading record. 

Heading searches are 30 characters long and must begin with the 
first word of the heading. The system assumes that all searches have 
been truncated and expands each one automatically so that ^very 
heading that begins with the search key used is retrieved. The 
Heading summary display lists normalized headings that match the 
search key, and like the title summary display, limited backwards 
scrolling functions are available. 

When the correct heading is located in the summary display it is 
then possible to instruct TALUS to display all the titles that are 
linked to that heading (remember that each heading is stored only once 
although it may have been used in conjunction with many titles). It 
will be possible to specify that titles are wanted that use the 
heading as an author, series, subject, or any entry. The summary 
title display that results from a heading search is much the same as 
the summary display that results from a title search. However, when 
accessed by heading, titles are not normalized for display and, thus, 
the summary screen includes characters that are translated or stripped 
out by the normalization process. 
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« 

Center for Library Automation 
416 Newman Library 
Virginia Tech 
Blacksburg, VA 24061 
(703) 961-5847 



VIRGINIA TECH LIBRARY SYSTEM 
BRIEF SUMMARY 



Virginia Tech Library System (VTLS) is designed to be an online, 
comprehensive, and integrated library system. VTLS not only 
automates the traditional library services, but also replaces the card 
catalog and most other manual data files. 

The system has been operational since 1976 and is presently installed in 
several locations in the United States and abroad. The salient features 
of the latest release of the system are the following: 

* Ability to handle full MARC records. Data entry is possible by (a) 
direct entry, (b) MARC tape transfer, and (c) OCLC interface 
module which permits direct transfer of data from OCLC terminals to 
VTLS. 

* Full online capability to retrieve and modify all data. Retrieval is 
^through all title fields, all author fields, alLsubject fields, all added 

entries, call numbers, barcode or OCR label numbers, and 
bibliographic control numbers such as OCLC number, ISSN, ISBN, 
and LC card number. Access to author/title mixed fields is by both 
author and title subfields. Further, the system allows for retrieval 
by partial call number. 

* ^ comprehensive circulation control module, which is well integrated 
with data entry and searching. 

* Ability to store, retrieve, and edit serials holdings records. The 
system also permits multiple bibliographic records to be associated 
\vith the same call number; this is of significant importance to 
serials management. 

* Ability to make global changes to author and subject entries. This 
means that corrections* to a single authority record are automatically 
reflected in all of its associated bibliographic records. 

* Ability to support multiple libraries with one or more computers. 
VTLS provides library networking features which allow access to 
and manipulation of local and remote files. 
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* Human-engineered system design which is based on the concept of 
screen networking. The system is easy for novices to understand 
and use, and it contains features that save time for professionals. 

* Easy to read screens. The data retrieved through numerous access 
points is logically sorted wherever appropriate, and the full ALA 
character set is properly displayed. 

The complete system documentation is available to systems users. The 
following featu^res are presently under development: 

* Coded Holdings ; 

* Serials Receiving and Claiming 

* Acquisitions and Fund Accounting 

* Management Reports 

* Comprehensive (MARC-Based) Authority Control 

* Reserve Reading Room Control 

The software is available from Virginia Polytechnic Institute and State 
University at a cost of $40,000, plus a maintenance fee of $250.00 per 
month. For full details, contact the Library Automation Project Office. 
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INSTALLATION POLICY 

c 

FOR 

VIRGINIA TECH LIBRARY SYSTEM 
(VTLS) 

A. SYSTEM INSTALLATION CONSISTS OF THE FOLLOWING : 

1. Installation of VTLS software. 

2. Determination and entry of institution-specific options. 

3. Training: 

(a) General systems usage (2 hours) 

(b) Circulation (multiple 1 hour sessions) 

(c) Data control (2 hours) 

(d) Systems operations (2 hours) 

(e) System manager (3 hours). 

Our system in very easy to use. Experience shows that this 
training schedule is sufficient. Additional training may be 
contracted for. 

B. PRE-INSTALLATION CHECKLIST : 

The user must insure that the following items are available prior 
to installation. 

1. Hardware: 

All hardware must be completely installed and fully 
operational. 

2. HP System Software: 

The required HP software consists of MPE/3000, 
COBOL I!, IMAGE, KSAM, SPL, and QUERY. 

3. Machine-Readable Data: 

If the user has machine-readable data that is to be 
preloaded into the system, then that data must be 
available in the agreed upon format and be error free. 
Should such machine-readable data require special 
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INSTALLATION POLICY CONTINUED 



PAGE 2 



handling, then Virginia Tech software engineers may 
be required to make a special site visit under mutually 
agreed terms ♦ . 

4. Individuals who are to receive training must be 
available during the installation period. Those who are 
to receive system operation and system manager 
training should be available for two full days. 



C. COSTS AND SCHEDULES : 

Installation normally takes three days. Additional days may be 
scheduled as required, subject to mutual agreement. Installation 
services are free; except for travel costs, so long as the normal 
installation schedule Is followed. Travel costs (transportation to 
and from Blacksburg, Virginia, plus hotel and meals) for no more 
than three individuals must be borne by the user. 
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MAINTENANCE POLICY 
FOR 

VIRGINIA TECH LIBRARY SYSTEM 
(VTLS) 



1. Software Maintenance Consists of Two Items: 



(a) Enhanced releases of the software. 

(b) Correction of any errors in the software. Data errors, caused 
by any reason, are the responsibility of the user. 

2. New Releases: 

(a) As they become available, new releases will be provided to 
those users who have been on a maintenance contract 
continuously. 

(b) New releases will be sent on tape to the user. The user 
should install these new releases as soon as possible. 

(c) It is the responsibility of the user to provide the necessary 
operating system and the compilers required for the software. 

3. Error Corrections : 

(a) Errors in the software will be corrected as soon as possible 
after they are brought to the attention of Virginia Tech. 

(b) The user must provide sufficient documentation for Virginia 
Tech to be able to re-create the error on the latest release of 
the software. Errors that cannot be re.-created on the latest 
release will be assumed to have been fixed in the latest release 
which should be installed by the user. 

(c) The user must provide a 1200 baud dialup port to enable 
Virginia Tech software engineers to access the user's system 
for problem resolution. Virginia Tech shall take all necessary 
steps to insure that none of the information or programs, in 
any form, acquired from user through accef>s to the user's 
system are made available to any other person, institution, or 
corporation. It will be the responsibility of Virginia Tech to 
reasonably insure that all individuals having access to such 
information or programs on behalf of Virginia Tech shall 
likewise observe this non-disclosure Agreement. 
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4. Costs: 

The maintenance costs for the software are $250 per month, payable 
in advance. Renewal of the maintenance will be at the then-current 
prices. 

5. Discontinuation of Maintenance : 

(a) Should user decide to discontinue maintenance for any reason, 
software suppqrt, problem resolution, and receipt of system 
enhancements will be discontinued. 

(b) user still will be required to pay a usage charge of $35.00 per 
month, payable annually in advance* 

(c) Maintenance may be restored by paying either 1) the back 
payments from the time of cancellation or 2) maintenance 
charges for twenty-four (24) months, whichever is less. Upon 
such restoration of rr^aintenance, user is then entitled to all 
system enhancements which have occurred during any period of 
discontinuance. 
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VIRGINIA TECH LIBRARY AUTOMATION PROJECT 
416 Newman Library ^ • 
Blacksburg, Virginia 24061 
(703) 961-5847 

VTLS INFORMATION FORM 
(Revised March, 1982) 



The information contained on the reverse side of this form will be 
used to assess the computer configuration required to adequately 
support your library's automation needs. The following instructions 
correspond to th^^ question numbers on the other side of this form. 
For all questions, please give your best estimates for both the 
present status and the projected ■ status in two years. 



1. TITLES: This refers to the number of uniqu e bibliographic 
records in your collection. 

2. ITEMS: This refers to the number of volumes (physical pieces) in 
your library. 

3. FULL MARC RECORDS: This refers to the number of full MARC 
records that you have in machine readable form, 

4. NON-MARC RECORDS: This refers to the number of bibliographic 
non-MARC records or abbreviated MARC records that are in machine 
readable- form- If you have such records , please provide the 
record layout on a separate sheet . 

5. ITEM RECORDS: This refers to the number of item records that 
exist in machine readable form, 

6. PATRONS: This refers to the number of library cards issue<i. It 
is not necessary to give information by branch. 

7. HOLDINGS RECORDS: This refers to records which the library 
wishes to express in ranges (serials, documents, etc.). 

8. MAXIMUM CIRCULATION: This number represents the maximum number 
of items that will be in circulation at any one time. Please 
provide best estimate. 

9. CIRCULATION ACTIVITY: This refers to the number of circulations 
per year by branch. 

The rest of the questions are self-explanatory. 
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PRESENT PROJECTED IN 2 YRS. 



1. Titles 

2. Items 

3. Full MARC Records 

4. Non-MARC Records 

5. Item Records 

6. Patrons 

7- -Holdings Records 

8. Maximum Circulation 

9. Circulation Activity 
10 • Yearly Attendance 
11. Number of Branches 



12. Will the system be used to totally replace the catalog? Yes No 

13. Will the system be used to compliment a "closed" catalog? Yes No 

14. Do you plan to use an existing HP-3000 system? If so, 
please provide the hardware/software configuration 

of the machine on a separate sheet • 

i 

15. Please indicate the source/method, used for creating 
bibliographic records. (Circle- all that apply) 



a. 


From OCLC terminals 


Yes 


No 


b. 


From LC MARC tapes 


Yes 


No 


c. 


From OCLC archive tapes 


Yes 


No 


d. 


From MARCIVE tapes 


Yes 


No 


e . 


From SCIENCE PRESS tapes 


Yes 


No 


f . 


From BLACKWELL N.A. tapes 


Yes 


No 


g- 


From AUTO-GRAPHICS tapes 


Yes' 


No 


h. 


Direct entry 


. Yes 


No 


i . 


Other 


Yes 


No 




(If yes, please specify) 







16. Institution Name: 
Address: 



Contact Person: 
Title: 



Telephone: 
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Library Automation Project 
416 Newman Library 
Virginia Tech 
Blacksburg, VA 24061 
(703) 961-5847 



LIBRARY POLICY INFORMATION REQUEST 
(Revised May 6, 1982) 



The follovying is a list of parameters which will be set at the time of VTLS 
installation. Because they are dependent on local library policy, their values 
must be established prior to the arrival of VTLS personnel. 

Patron Parameters 

Define up to five (5) different classes of library patrons. (NOTE:^ The 
labels for the five possible patron classes are "FC", "ST", "OT", "GD",.and 
"UG".) For each patron class defined, provide the following information: 

1. Circulation period (in days). 

2. Overdue fine (in cents per item per day). 

3. Should the patron be blocked from circulation, if his fines 
exceed a given limit? If so, what is the limit (in dollars)? 

4. The period of tim6 (days from last update of record) after 
which the patron's record is deleted from the system, if he 
does not have any outstanding materials or fines. ^ 

5. The period of time (days after last update of record) after 
which the patron*s record is deleted iYom the system 
regardless of outstanding materials or fines. 

Gs' The number of times the patron may renew aw item. 

item Parameters 

Define up to .400 classes of items which have different circulation periods. 
Ror each item class, provide the following information: 

1. Circulation period (in days). 

2. Overdue fine (in cents per day). 

3. The number of times the item may be renewed. 

NOTE: For circulation period, the system uses the lesser of the values 
specified for the item and patron c|^ss of the particular circulation 
transaction. For both renewal limit and overdue fine, the system uses the 
larger of the values. An exception is made when the overdue fine is 
' specified to be zero for that entire class of patrons. When this is the case, 
no fine is charged, regardless of the specification for the item class. 
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Fine/Grace Parameters 

1. The number of grace days to be granted in the calculation of overdue 
fines. 

2. The maximum fine to be charged a patron for a single overdue item. 



Subject Access Parameter 

Specify the values for the indicator of the MARC 6xx fields by the subject 
access desired. 



Call Nunjber Access Parameter 

In cases of multiple call number entries within MARC records, specify the tag 
used locally. 



Letter Control Parameters 

1. The number of days between the due-date and the first overdue notice, 
and the number of days between the first and second overdue notices. 

2. The number of days between the due-date and the overdue bill. 

3. The minimum circulation period before which an item may be recalled by 
another patron. 

4. The number of days allowed for the patron to receive the first recall 
letter in the mail. (When the due date is changed because of the recall, 
this mail delay will be considered in the calculation of the new date.) 

5. The number of ^ days between the first and second recall letters, and the 
number of days between the second and third recall letters. 

* 

Text of Letters 

Please review the attached letters and note any desired changes. Be aware 
that some of these letters are categorized by patron class. 

Other Defaults 

1. The default circulation period to be used during data entry of items. 

2. The initial entry^ default for city, state, and zip code within a patron's 
address, * * 

3. The default item price to be used in printing overdue notices and bills. 
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I . Introduction 

A. Charge 

As specified in Appendix 1, the Task Force was charge with iden- 
tifying the University Libraries circulation system requirements, 
comparing requirements with available automated systems including- our 
Library Control System (LCS), and developing costs estimates: 

1) To maintain LCS as it presently is, 

2) to expand or enhance LCS, or 

3) to develop or install a completely new automated system. 

Because this study is only one part of the larger long-range 
planning effort to identify library automation requirements, the Task 
Force concentrated on defining circulation requirements in detail. 

B. Selection of Systems to be Investigated 

The Task Force examined circulation requirement specifications 
defined by other libraries, read recent reviews of existing circula- 
tion systems, surveyed the library literature, and selected four 
systems for closer examination. 

The primary purpose for examining available circulation systems 
was to identify the variety of systems and options available, rather 
than to evaluate each system for selection. The system are changing 
so quickly that an in-depth evaluation should take place just before 
a system is selected. 

The Task Force selected four systems for in-depth study; 

1. OCLC's Total Library System (TLS) and Local Library System (LLS). 

2. DataPhase's Automated Library Information System (ALIS). 
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B. Selection of Systems to be Investigated - Cont. 

3. CLSrs LIB 100 System. 

4. GEAC's Library system. ; 

, OCLC's Total Library System and Ideal Library System were selected 

as examples of circulation systems provided by a bibliographic utility, 

and because of the high probability that many SUNY/OCLC libraries will 

use one of the 'systems when they become available. The GEAC system 

was selected because several large academic libraries including several 

members of RLIN have it, and SUNY Buffalo has asked to acquire it. The 

DataPhase and CLSI systems were selected because they are systems which 

have been widely installed in public and academic libraries and have 

H 3 

been in operation for more than five years in some libraries. 

The selection of these systems does not imply that these are the 
only available systems, and we must point out that by limiting our 
examination to these systems, we may have overlooked cenain unique 
capabilities offered by other systems. These were selected for study 
because they appeared to represent the beSt automation options available 
to SUNY Albany at the present time. x 

It is important to note that we constd^ed LCS to be an example of a 
circulation system developed or enhanced by a u|iiversity library and 
therefore did not select another of this type for study. We did not 
examine a micro-computer based circulation system (e.g. Gaylord) be- 
cause we did not find any such systems operating in large academic 
libraries. 
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V. Reconmendations 

1. The Task Force recommends that the University Libraries replace ICS 
with another automated circulation system: 

a. Maintaining the LCS software requires an on-going commitment of 
computing professionals. Using a vendor-maintained system 
cou.u save two staff positions. 

b. Enhancing LCS software to have comparable capabilities with current 
turnkey systems would require many staff -years of programming. 

c. While LCS has served our circulation needs in the past, declining 
staff make it necessary to automate additional functions such as 
Reserve circulation in order to maintain current service levels. 

d. Since newer and more sophisticated circulation systems are now 
available, it is unlikely that other libraries would ever share 
LCS and its costs with us. 

2. The Task Force recommends that the University Libraries purchase a 
"turnkey" circulation system that presently is in use in academic 
libraries of equal or greater size : 

a. The vendor would be contractually bound to provide a complete system 
at a fixed cost including installation, staff training, software 
maintenance, and enhancement, and hardware mainterance. 

b. The libraries could make a single "quantum" leap in system capa- 
bilities. 

c. Purchasing such system could be financed over five to ten years 
out of the money now budgeted for LCS. Inflationary increases 
would be limited to maintenance and communication charges. 
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Recommendations - Cont, 



d. If the system is performing satisfactorily in other academic li- 
braries of equal or greater size, the system is most likely to meet 
our circulation requirements. 
■ e. A new system would improve the libraries' services, ability to be 
responsive to user needs, provide additional services not presently 
available which would reduce overdue fines collection and billing 
paperwork, and provide management information not presently avail- 
able. 

3. The Task Force recommends that online systems for circulation and the 
eventual online catalog be integrated : 

a. Users of the online catalog need to know not only whether the li- 
brary has an item but also whether the item is available. 

b. Use of the circulation system for inventory control requires that 
bibliographic information in the circulation system be as accurate 
as possible, and identical to the information found in the catalog. 

4. Regarding automatic input of unique item and patron numbers, the Task 
Force recommends the following : ^ 

a . That barcodes be used instead of OCR (optical character recognition) . 
Reasons : 

i. Barcode light pens can be held at a greater variation of angles 
than OCR light pens. 

ii. Barcodes are less susceptible to reader failure due to print 
defects. 

iii. Barcodes are more difficult to plagiarize than OCR labels. 

iv. Barcodes are in more common use in libraries. 

46 . 
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Recoflinendations - Cont. 

b. That the Libraries adopt the Monarch CODABAR format which has be- 
come a standard for library circulation systems ^ 

Reason: 

i. This will ensure compatibility. with whatever library circula- 
tion system we obtain in the future, 

c . That the libraries begin to investigate a method of converting to 
barcodes dnd begin bar-coding new acquisitions as soon as possible . 

Reason: 

i. This will reduce conversion efford when the bar code readers 
are installed. 

5. That priority be given to identifying and correcting errors in the biblio- 
graphic records used in the online circulation system . 

a. Errors and inconsistencies in entry of bibliographic information 
result in erroneous avcri^ilHy information being given to patrons 
and staff. 

21 

b. According to a study of searching on the SUNY Albany LCS system, 10% 
of all bibliographic records contain errors that would prevent them 
from being retrieved, and 18% of all searches produce erroneous re- 
sults because of errors in bibliographic data, 

c. Unless these errors are' corrected, they might be carried over into 
the future online catalog. 
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V. MASTER BIBLIOGRAPHIC REdbRD (MBR) 

5#0 The core of the on-line automated integrated library system planned for 
The University of Tennessee^ Knoxville Library is a bibliographic file 
consisting of master bibliographic records (MBRs) for every title' ovmed 
by the Library. The bibliographic file must be shared by all modules 
or subsystems in the integrated library system* This section will 
discuss the MBRs which reside in that file in terms of: 1) their source 
and general characteristics; and 2) requirements for their storage, 
manipulation, and display* (Appendix B should be consulted for further 
details on the structure and format of the MBRs currently appearing on 
the OCLC archival tapes.) 
5.1 SOURCE AND GENERAL CHARACTERISTICS 

5.1.1 The current source of the Library*s MBRs is the OCLC system. The 

Library*s existing MBRs are stored on conventional OCLC archival tapes. 
However, the system must be capable of integrating into the bibliographic 
file MBRs which may be received from other bibliographic utilities or 
from other standard sources, such as the Carrollton Press RIMAKC Project 
or the Library of Congress. 

5*1^.2 The system must provide complete interfaces between itself and the 
bibliographic utility so that complete machine-readable MBRs can be 
tran'sferred directly from the utility's local terminals to the local 
bibliographic file. Bidder must agree to upgrade the system* s software 
so'^hat-this capabil^ity will not be lost in the event of any future chatiges 
' in t^ie format or display of bibliographic recbrds by the utility. 

5.1.3 /Th^ system must provide a *'workfonn" for the on-line creation of MBRs when 
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5.1.3 (contd) ^ 

special circumstances dictate that use of the utility would be 
cumberaoaie or Inappropriate. 

5.1.4 The system oust have the capacity to accept and store full OCLC/MARC 
records (or the MARC records of other utilities). The system also must 
accept MBRs which are less than "full/' e.g. 'OCLC ,Acvel "K" records.. 
(See Library of Congress. MARC : Composite format for full definition 
of MARC records.) 

5.1.5 MARC records may contain any character fpund in the current ALA 
character set. Provision must be made for these and for any future^ 
increases In this number. The system must be able to accept non-roman 
characters as the utilities develop the capacity to handle them. 

5.2 .REQUIREMENTS FOR STORAGE, MANIPULATION, AND DISPLAY 

5.2.1 The system must be capaj»le of providing for the conversion of the 
Library's IffiRs, whether represented on OCLC archival tapes or other 
standard sources, to the appropriate format for use in any modules 
or subsystems. 

5.2.2 The system must have the capability to input/output and display 
bibliographic data in national/international machine-readable formats — 
currently MARC II and other LC MARC formats — for each item regardless 
of the medium, including monograph, serial, document » map, score, 
manuscript, sound recording, and audiovisual £lus other standard 
formats as they are developed. The system must not 'lose any of the 
tags, codes, delimiters, or any special designators of an MBR entering 
the bibliographic file so that it vill be possible to display and 
output a wholly reconstructed MARC record. 

5.2.3 The Library's MBRs include holdings information in 049 and 590 fields. 
(Described in detail in Appendix B.) The system must store and display 
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5.2.3 (contd) 

complete holdings Infonnatlon sufficient to distinguish each 
physical item. Items must be distinguished either by identification 

f 

number (barcode number or by detailed call number - copy, volume, 
part, etc.). The holdings statement should be able to accommodate 
both methods. For monographic sets, holdings should show the 
specific volumes in the set.''^ For serials, the system should give 
a summary of- holdings as well as detailed holdings. 

The system must permit on-line modification of individual or multiple 
fields within MBRs in the bibliographic file and aust not require 
reconstruction of the entire record for eaph transaction. The system 
must pex-mit the deletion of entire records. -Until an on-line catalog 
is available, the Library wishes to keep the bibliographic file 
current with its own card catalog, requiring frequent "maintenance" 
types of activities. Changes also may be necessary to remain current 
with LC practice. Changes to existing machine-readable records 
currently are accomplished using OCLC, requiring complete reconstruction 
of each record followed by a PRODUCE or UPDATE command. These changes 
currently number approximately 2500 withdrawals, 1500 transfers .(changes 
of location), and 6000 changes in the content of individual records 
per year. 

5.2.4 The system must be able to generate reports on demand. The system 

must be able to provide statistics from specific bibliographic 

collections by time period. The system must be able to provide 

t 

a listing of records which lack specified data elements. Statistical 
Information must include, but is not limited to: 

- Number of bibliographic units cataloged by title count / 

' ■ 54 
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5.2.4 . (contd) 

.'^•^ - Nufflber of bibliographic units cataloged by volume count 

- Bibliographic units cataloged, breakdovm by classification 
number, then" by title count 

- Bibliographic units cataloged, breakdown by classification 
number, then by colume count 

- Number of bibliographic units cataloged for any specific 
bibliographic collection, by title count 

- Number of bibliographic units cataloged for any specific 
bibliographic collection, by volume count 

' , - Breakdown by format (i.e., f>ound recording, microform, etc.) 

^ Number of bibliographic records maintained by the system 

- Number and category of changes made to MBRs during any given period, 
including titles and volumes withdrawn from each bibliographic 
collection 

5.2.5 The IffiR ultimately must be retrievable through all data elements of 
the record. Initially, however, the MBR must be retrievable by 
search keys including, but not limited to the following: , 

- personal name 

- corporate name 

- conference name 

- title 

- uniform title 

- any combination of name/title 

- subject heading 

- series 

- classification number 

» 

' - LCCN 

' ' - ISBN, ISSN, CODEN, bibliographic utility record number, GPO stock 

i 

r^J^^ number, or other number 

E^. 55 
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5,2.5 (contd) 

- system assigned control number 

- barcode/OCR-A label number 

It should be possible to refine any search key by the addition of 
qualifiers; e.g., format, Imprint date or range of dates, place, or 
other sub-element. It is desirable to be able to search the 
bibliographic file using Boolean logic connectors "and," "or," and 
"not." If this feature is available, an on-line instruction module 
for its use is also desirable. Access by partial field content and 
combinations of fields is highly desirable. 
5,2-^ Authority control 

5,2,6.1 Ultimately, the entire bibliographic file must be subject to the control 
of an authority system. This section is included in the present document, 
since it is desirable for the authority control system to be installed 
in advance of the on-line catalog module, thereby permitting improved 
public access capability as public access terminals are introduced. 

5* 2. 6,2 ^or the purposes of this document, an authority system is defined as 
a mechanism to record a standardized form of a heading and to ensure 
consistent use of that standardized form throughout the bibliographic 
file. The word "heading" is defined as used in AACR2: a word or phrase 
used as an access point in a bibliographic record (author, subject, 
series, etc.). The title of a work (in this context) generally is not 
considered a heading unless used as a uniform title or series entry. 

5,2.6.3 Authority control must include but not be limited to: 

- Names — personal, corporate, conference, geographic 

- Topical subjects 

- Uniform titles 

- Series — must include decision of series treatinent as well as 
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5.2.6..4 The authority control system must be based on the MARC authorities 

format. The system must input, display, and output authority records 
in the MARC or MARC compatible authorities format. The system must 
. be capable of incorporp.cing future changes in the MARC authorities 
format, or new national standard formats as they are developed. 
The system must have the capability to accept authority records 

from in-house generation, or from external sources, including but 
not limited to: bibliographic utilities. LC, and other standard 

sources. It must be possible to identify the source of the 

authority control record. 

5.2.6.5 The authority system must allow on-line addition, deletion, or 
modification of entire authority records or individual fields within 
authority records. The authority system must provide a global search 
and replace function, in order to facilitate change of every 
occurrence of a heading in any MBR, with a single change of that 
heading in the authority file. 

5.2.6.6 The authority system must be capable of linking automatically any 
heading in the authority file to each occurrence of that heading in 
designated fields and/or subfields in all MBRs. The system must be 
capable of Unking automatically any heading in the authority file 
to any occurrence of that heading elsewhere in the authority file. 

5.2.6.7 It must be possible for the system to match LC or other national 
standard authority records against the bibliographic file initially 
and periodically in order to ensure that the bibliographic file 

will remain consistent with LC and/or other national standard practices, 
The system must be capable of flagging or otherwise calling attention 
to a heading in designated fields and subfields of MBRs for whxch a 
match does not 'exist in the authority file. 
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5,2,6,8 The system must be able to generate reports on demand. The 

system must be able to provide statistics by time period, and 
statistical information must include but is not limited to: 

- Number of heading changes mada 

- Number of MBRs affected by a heading change 

- Number of authority records maintained by the system 



ERIC 



Ob 



49 



SELECTED SECTION 



A Request by 
Dartmouth College Library 
For Proposals 
Regardin g an 
Automated Circulation System 



7 May 1982 

Dartmouth College Library 
Hanover, NH 03755 



ERIC 



50 



ft 



Introduct ion 

The Dartmouth College Library is seeking to install an online 
circulation system as an enhancement to its general program of 
library automation. To that end, the Library is requesting 
proposals from vendors based on the requirements outlined m this 
document . 

Institutional Background 

Dartmouth College, founded in 1769, is a private educational 
institution with an enrollment of approximately 4000 students. 
Three associated professional schools are also located on campus: 
Thayer School of Engineering, Tuck School of Business 
Administration, and Dartmouth Medical School. The Dartmouth 
College Library system supports these undergraduate and graduate 
programs through a network of eight libraries. Baker Library 
contains the humanities and social sciences collections and seven 
more specialized libraries house collections in various 
disciplines. In addition, there is an off-campus storage library 
housing- seldom-used material. In all, the collection contains 
1.5 million volumes (including over 40,000 serial tit.los), 95,000 
maus, 860,000 microform items, audiovisual materials, and 
artifacts. In 1969, Dartmouth joined the Association of Research 
Libraries and, in 1979, became a member of the Research--Librar les 
Group. 

Dartmouth College has long been innovative in utilizing computer 
technology in administrative as well as educational processes. 
The Kiewit Computation Center provides central support for 
computer applications at the College. Most students will have 
used a computer terminal before graduating from Dartmouth and 
most employees find computers an integral part of the workplace. 
This is especially true of the Library. The library 
administration strongly believes that as the cost of library 
operations continues to increase, computer technology can provide 
more effective service for users with cost-saving advantages for 
library operations. With this in mind, the Library established 
an automation program in 1969. The Automation Department has 
overseen the production of Dartmouth's Union List of Serials as a 
computer output microform product as well as the computerization 
of the Library's acquisition functions. Several other programs 
provide such services as statistical record-keeping and billing 
to college accounts. The Library also utilizes the OCLC network 
and the Research Libraries Group RLIN shared cataloging system. 
Computer literature searching services arc provided by the 
Library through several commercial vendor systems. 

Since 1979, Dartmouth has been developing an online catalog 
system for all library users. The online catalog is designed so 
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that users can operate the system without any special computer 
skills or library training. Users will be able to search over 
450,000 records. The online catalog is now available to users 
through the Bibliographic Retrieval Service computer in Latham, . 
New York, but will soon be available on a local Library computer. 

The next phase of development calls for the Dartmouth College 
Library system to integrate its online catalog with an online 
circulation system. Dartmouth is therefore looking for a system 
with appropri'^te design features to provide effective user 
service and the cost-saving advantages required by the Library's 
automat i on program* 

Functional Requirements 

The successful vendor's proposal shall respond in detail to the 
functional requirements outlined in this section* The following 
specific requirements are noted here because of their importance 
in a successful installation of a circulation system at 
Dartmouth: 

o Circulation rules for various classes of it>:. is may vary 
with different borrower classes and different 
libraries. Designated operators must be able to 
override these rules. 

o The status of any item should be updated online so that 
all inquiries will give up-to-date information. 

o The system to be installed should have demonstrated a 
high degree of reliability regarding online system 
performance and data security. 

o Due to the staffing situation at circulation locations, 
it is important that the system be designed both for 
easy operation by inexperienced operators and for quick 
operation by experienced operators. 

o The circulation system must have rapid response time 
for all functions, especially those involving immediate 
borrower service. 
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The following paragraphs briefly describe the major requirements 
of the circulation system to be installed: 



Borrower Files 



The system shall support a borrower list of 
approximately 12,000 persons, representing several 
different classes of borrowers. The data may be 
entered either directly online or by magnetic tape or 
disc from an existing file of student, faculty, and 
staff data. The borrower files should be- constructed 
so that borrowers may charge out materials on their 
first visit to" the library and so that statistics may 
be compiled for various subclasses of borrowers. 
Each class of borrower may have unique borrowing 
privileges for various classes of items at each 
agency. 



Item Piles 



Initially the system shall have the capacity foi 
750,000 brief records with provision for adding 
records for 30,000 volumes per year for the next five 
years. These records may be entered either online or 
by batch load from magnetic tape or disc. There 
shall be provision for as many. as 100,000 items in 
the checkout file at any one time. The 
identification of all items shall be volume and copy 
specific In addition to the standard bibliographic 
information about an item, a circulation history 
should also be stored indefinitely. 



Inquiry 

Users shall have access to the information stored in 
the system with varying levels of inquiry permitted. 
Some information shall be available to everyone and 
other information shall require access permission. 
The access points should include call number, author, 
title, item ID number, subject, borrower ID number, 
and borrower name. 
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Checkout 



This online activity must combine fast service with a 
variety of checks — both of the patron and the item-t~ 
ensuring that each transaction is consistent with 
circulation policy. Designated operators shall be 
able to override any block (see below) signalled by 
the system* ^ ^ - 

• » 

Reserve Book Circulation 

The system shall support an hourly and daily loan 
system for items placed "on reserve". It must be 
easy to change the standard reserve loan to an 
overnight loan coming due at a specified time the 
next day. It is highly desirable that reserve and 
general circulation be treated as a single function. 
The circulation system should be able to generate 
lists of reserve materials by term, course, 
professor, or reserve location. 



Checkin 

Items may be checked in at any circulation terminal 
or at a special checkin terminal, if the vendor 
provides such a terminal. The status of each item 
will always be verified before checkin is final; The 
system should effectively signal the occurrence of 
any condition other than being ready to reshelve. 



Fines 

Fines will be variable, depending on borrower status, 
item status, and owning agency. The system shall 
provide for grace periods and operator overrides. It 
should be possible to tie this function to the 
college billing system with provision for monitoring 
by staff persons. 



Renewals 

This function should be performed with or without the 
borrower *s ID card. The system shall have 
appropriate checks to verify that an item is eligible 
for renewal before signalling the transaction. It 
should be possible to renew with one command a whole 
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group of items, such as all items charged to a 
particular borrower* 



Holds 



Holds may. be placed either by librar> staff or by 
persons querying the Dartmouth Online Catalog. Items 
will be placed in queue on a first in first out basis 
with provision for altering the order of the queue* 
A hold may be placed for any item in the system at 
any terjninal |n the system* 



Recalls 

Items may be recalled by designated operators 
according to policy as it exists in an item's owning 
agency. Recalls may be initiated in any location for 
items in any location. The system shall not only 
generate notices at the appropriate time, but shall 
provide follow-up checks for non-compliance. 



Intralibrary Loans 

The system shall easily allow temporary reassignment 
of an item from one library to another. This feature 
will be especially important for the Storage Library 
and reserve reading rooms. 

Interaction with the Dartmouth Online Catalog 

The circulation system shall be able to interact with 
the Dartmouth Online Catalog. Users of the catalog 
should be able to determine the status of particular 
items and to place holds on items that are not on the 
shelf. ; 



The system shall employ a variety of function blocks. 
These blocks should occur wherever policy requires 
human discretion* — such as borrower delinquency, a 
message, or a hold on an item. There should be 
provision for varying levels of override authority 
among system operators with respect to these function 
blocks. 



Blocks 
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Notices 



A variety of public service notices shall be 
generated on demand or automatically at predetermined 
times . These notices may include recall , renewal^ 
overdue, hold, fine, and special information notices. 
Each library will determine its own policy regarding 
the sending of notices. The system should create 
preaddressed notices. In addition to these batch 
produced notices, there should be printers available 
to produce paper copy lists, receipts, or notices at 
checkin and checkout locations. 



Reports ^ 

The system shall monitor itself and the various 
transactions that it records. These reports shall be 
produced at designated intervals or on '^demand in a 
way that system performance, public service, and 
technical processes can be easily evaluated. Such- > 
reports may include listings of . overdues ^by agency 
and/or borrower subclass. It shall be possible to 
determine various collection usage patterns by call 
number category, time, material type, location, 
borrower subclass , etc. 



Response Time and Reliability 

The response time for all online functions shall be 
less than five seconds, with the system being 
operational 98% of the time that the library is open 
for circulation. 



Security 

The various functions of the system should operate 
with various levels of security to protect 
information that is confidential and to make 
available to everyone information that is not 
confidential. The preferred approach to security 
shall be through a password system. 
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Functions to be performed include: (a) selection entry and review; (b) ^ 
requisition preparation; (c) receiving; (d) fund accounting; (e) claiming 
and cancelling; (f) supplier file creation and maintenance; and (g) statis- 
tical reports display and printing. 

2.k Desired Equipment Configuration 

2.4.1 Summary of Equipment 

The following is a summary of the equipment expected to be bid: 

1— -Central Processing Unit, Operator Console / etc. . 
* Magnetic Disk Storage and Controllers 

2 — Magnetic Tape Drives and Controllers 
1 — Line Printer and Controllers 

1 — Character Printer and Controller 
104 CRT Terminals 

15 Optical Scanners and Controllers 

2 Portable Terminals 

16 — CRT Screen Printers 

33—-12O0 Baud Modems (or equivalent arrangement) for Remote Sites 
11~-1200 Baud Dial-Up Modems for Remote Sites 
1 Communications Processor/Control ler 

The number and type of modems may vary depending upon how a vendor bids 
the communications equipment. The communications processor or equivalent 
equipment may also vary. 

2.4.2 Distribution of Equipment 

The equipment above will be distributed in the following locations: 



M.D. Anderson Library 



1— -CPU, Operator Console, etc. 
-Magnetic Disk Storage and Controllers 

2 — Magnetic Tape Drives/Controllers 
1 — Line Printer and Controller 

61 — CRT Termi nal s 

1 — Computer Room 

k Cataloging Department 

k Acquisi tions Department 

k — Serials Unit 

1 — Reference Office 

1---ILL Office 

1 Documents Office 

6---Ci rculation Department 

3 — Reserve Room 

2 Audiovi sual Servi ces 

2 Information Desk 

10 — Card Catalog Area 

4- --PRR 

1 — Special Col lections 

70 
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— Floor 2 
— Floor 3 



\ 



\ 



3 — Floor k 

2— -Floor 5 

2— -Floor 6 

2 — Spares 
9 — ^Optical Scanners/Controllers 

^ — Circulation Department 

2 — Reserve Room 

1 — Catalog Department 

1 — Audiovisual Services 

1 — Spare 
7-— CRT Screen Printers 

1 — Catalog Department 

1- --Acquisitions Department 
1 — Serials Unit 

1 — Circulation Department 

2 — Information Desk 

1 — Aud iovi sual Serv i ces 
2 — Portable Terminals 
1 — Communi cat ions processor/Control ler 



Architecture Library (Central Campus) 



k — CRT Terminals 

1 — Optical Scanner/Control ler 

1 — CRT Screen Printer 

k — 1200 Baud Modems (or equivalent arrangement) 



Optometry Library (Central Campus) 



k — CRT Terminals 

1 — Optical Scanner/Controller 

1 — CRT Screen Printer 

k — 1200 Baud Modems (or equivalent arrangement) 



k — CRT Terminals 

1 — Optical Scanner/Control ler - 
1 — CRT Screen Printer 

k — 1200 Baud Modems (or equivalent arrangement) 



Pharmacy Library (Central Campus) 



k — CRT Terminals 

1 — Optical Scanner/Controller 

1 — CRT Screen Printer 

k — 1200 Baud Modems (or equivalent arrangement) 



k — CRT Terminals 

1 — CRT Screen Printer 

I4 — 1200 Baud Modems (or equivalent arrangement) 



Music Library 



(Central Campus) 



Law Library (Central Campus) 
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Downtown College Library 



12-- -CRT terminals 

2-— Optical Scanners/Controllers 

2— CRT Screen Printers 

] — Character Printer/Controller 
12—1200 Baud htodems (or equivalent arrangement) 

Clear Lake City Campus Library 



2 — CRT Terminals ; 

— CRT Screen PriiVjter 
2- — 1200 Baud Dial.-^p Modems* 

Victoria Campus Library 



2---CRT Terminals 

1---CRT Screen Printer 

2 — 1200 Baud Dial-Up Modems 



Other 

Dial-up terminal systems for installation in of f ices/ 1 aborator ies on the 
Central Campus (to be purchased only if funds are available). 

7 — CRT Terminal s 

7---1200 Baud Dial-Up Modems 

2 >5 Data To Be Maintained and Work Loads 
2.5.1 Bibliographic Records 

Machine- readable bibliographic records in OCLC/MARC format will be used to 
load the Public Online Catalog. The average length of these records wiH 
average approximate y 800 character/bytes. 

The initial load of bibliographic records is as follows: 

UHCC Libraries 250,000 

UHCC Law Library 20,000 

UHDC Library 150,000 

UHCLC Library 170,000 

UHVC Library 1^^0,000 

730,000 TOTAL 

The amount of dupl ication among thes> files is unknown. 

In addition to the initial load, bibliographic records will be added regular 
1; on aS annual basis. An estimate of the number of bibliographic records 
to be added fhe first year after the initial load is as follows: 

UHCC Libraries 100,000 

UHCC Law Library 3,000 

UHDC Library 12,000 / 

UHCLC Library 7,000 

UHVC Library 8,000 

O 130,000 TOTAL 

ERIC ^63 



2,10 System Re 1 iabi 1 I ty Acceptance Test 



2J0J A System Reliability Acceptance test shall be conducted onsite after 
the vendor has installed the system and has certified in writing that 
the system as specified in this IFB Is operational. 

2.10.2 The system shall operate at an average level of reliability of no less 
than 37% for a period of kS consecutive days. 

2. 10.3 The average level of rel iabi 1 ity shall be determined as follows: 

The downtime factor shall be cal culated by. mul 1 1 pi y ing 
the downtime hours (those daily operational hours between 
the time the vendor has been notified of a system failure 
and the time the system is fully operational) by a downtime 
coefficient, as defined in a Downtime Coefficient Table, for 
example: 

Failure Coaf f icient 



Critical Operations Failure; e.g.: 

Online Catalog Record Creation 

and Maintenance 1 -0 

Online Catalog Searches/ i nqui r i es 1.0 

Charge and Discharge 1*0 

Holds and Renewals 1 -0 
Borrower Record Creation and 

Maintenance ' -0 

Selection Entry and Review 1-0 

Requisition Order Preparation 1.0 

Receiving ^ -0 

Non-Critical Operations Failure; e.g.: 

Report Printing 0.25 After 24-Hour 

Grace Period 



Other Software Failures Not Significantly 
Affecting System Operation 



0. 1 Begi nni ng 5 days 
After Service Cal 1 
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Hardware Failure: e.g.: 

Central Processing Unit 
Disks (all) 

Individual disks, if system 

operational 

Tape Drive 

Line Printer 

Serial Printer 

CRT Termi nal 
Optical Scanner 
CRT Screen Printer 
Communications Equipment 



; .0 

1 .0 

0. 1 Per disk 
1.0 



0 
0.1 
0.25 
0.1 



After 2i»-Hour 
Grace Period 
Per Terminal 
Per Scanner 
Per Pr i nter 
Per Piece 



Z.IO.'* Total system downtime shall equal the sum of the downtime factors 
divided by the sum of dally library operation hours. 

2J0.5 Maintenance logs shall be kept by the Libraries In order to facilitate 
the measurement of system reliability* 

_ 2. 10.6 Downtime shall be calculated to the nearest. one-tenth hour and calcu- 
lated as a percentage of the library total operating hours during 
the period, 

2.10.7 In the event of a failure to meet the 3% downtime maximum, the ^5 

days acceptance test shall begin again when the 'problem is resolved. 

2.11 Full-Load Response Time Acceptance Test 

2.1K1 A Full-Load Response Time Acceptance Test shall be conducted onsite 
after the vendor has installed the system and has certified in 
writing that the system as specified In this IFB is operational, 
after all software has been installed and passed the Functional 
Acceptance Tests, and after the initial bibliographic data file has 
been loaded. 

2.11.2 The Libraries shall provide operators, test log keepers, and data 
recorders for each terminal, during the tests. 

2.11.3 The test shall evaluate the system within the following constraints: 

a. A library-specified mix of terminal dedica*-ions ; e.g., 

50% of the terminals dedicated to the searcnes/inqu i ri es in the 
Public Online Catalog; 20% to data input-edit; 15% to 
circulation; and 15% to acquisitions. 

b. A library-specified *'peak load*' or "worst case" job mix; 
e.g., 1,000 .charge and renewal transactions; 200 discharges; 
200 file inquiries (100 of which are subject inquiries); 

100 data input-edits, 2 hatch-mode jobs, in a single hour. 

2. 11. A The test shall provide unequivocal evidence (i.e., the results may 
be entered into a written log) that the system meets response-time 
performance requirements under the "peak load" condition. 

2.11.5 The test results may be inspected and evaluated by a consultant or 
other library- or vendor-specified party. 

2.11.6 The system shall, operating in the worst case test, exhibit average 
response times not exceeding: 

a. Six seconds for data input-edit. 

b. Six seconds for file inquiries by non-subject index. 

c. Eight seconds for file inquiries by subject index. 

d. Two seconds for charge, renewal, discharge, and other 
circulation and acquisitions functions. 
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2.11.7 



Average system response times are the totals of all the transaction 
times In a category (e.g., charges) divided by the total number of 
transactions In those categories. 



2.12 Payment 

2J2.1 The Libraries plan to pay for the system In. three payments: (a) 

approximately 50% of the total system cost shall be paid upon the signing 
of a contract or agreement with the vendor, as a down payment; (b) 
approximately 25% of the total system cost shall be paid upon passing 
of the three system acceptance tests; and (c) the balance shall be paid 
approximately six months after the second paymerrt.- 

2.12.2 Upon Installation, acceptance, and final payment, the Libraries shall 
receive clear title to all hardware and all software not under a 
licensing arrangement. 
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6. HARDWARE SPECIFICATIONS 

(Vendors are reminded that they must respond to each specification In this 
section by indicating one of the following in the appropriate part of the 
Specification Response Form at the end of this document: YES (feature or 
function is available); YES/D (feature or function is available, but with 
minor differences noted); YES/F (feature or function will be available at 
date specified); and NO (feature or function not available). 

6. 1 General 

6.1.1 All hardware shall be unmodi f ied, "of f-the-shel f" .equipment . 

6.1.2 All hardware shall have a 90-day warranty, effective from the 
date of instal lation. 

6.1.3 All hardware shall be new, a part of the vendor's standard product 
line, amd certified as maintainable. 

6.1.^ All essential cabinets, controllers, cabling, and other interfaces 
shall be provided as part of a bid. 

6.1.5 All hardware shall be certified to qualify for ful 1 -coverage preventive 
and remed i a 1 ma i n tenance 

6.1.6 (Optional) The system shall accept a mixture of different manufacturer 
CRT terminals. 

6.2 Central Processing Unit 

6.2.1 The Central Processing Unit (CPU) bid for Initial Installation shall 
have sufficient input/output paths, core memory, and other features 

to perform the expected workloads described in Section 1.5 and to allow 
concurrent operation of the peripherals Identified in Sections 6.2 
through' 6.10. 

6.2.2 The system bid shall be a multi-processor unit-. 

•'1 

6.2.3 Each processor of the CPU shall have its own individual power supply 
and input/output channels to ensure continuous processing should one 
processor fai 1 . 

6*2. A Each proces^sor shall work concurrently and share the computing load 
between them tO' increase total system capacity. 

6.2.5 In case of failure of one processor, the system shall automatically 
shift the system's workload to the remaining processor (s ) , without 
human i nter vent ion. 

6.2.6 The CPU bid shall be capable of accepting modular additions to memory 
up to twice the installed core memory, through addition of memory in 
each processor and through addition of additional processors, without 
reprogrammi ng. 
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6.2.7 The system bid shall Include a console with keyboard and visual 

. display for communication between an operator and the computer and 
for control of batch programs. 

6.2.8 The system shall have, power failure protection for the equipment. 

6.3 Magnetic Disk Storage ' 

6.3.1 Sufficient disk storage shall be bid to store the initial files described 
in Section 2.5 and to store the additional records expected to be 

added for three years after installation, at .the rates defined in 
Section 2.5. 

6.3.2 Sufficient additional disk storage shall be bid to store the system 
software and other software. 

6.3.3 Tne system shall be expandable in the future to at least double the disk 
storage capacity without need for additional disk controllers and without 
changing the basic hardware or software, except for adding new disk drives 

6.3.^ A disk pack shall be included for each drive bid, plus sufficient scratch 
packs required for system maintenance. 

6.3.5 Sufficient disk packs shall be included to accomodate the total backup 
system recommended by the bidder. 

6.3.6 All disk packs shall be error-free and formated. 

6.^ Magnetic Tape Drives 

(•Note: The second drive will not be purchased if sufficient funds are not 
aval lab le) . 

6.4.1 The tape drives bid shall include necessary control le'"s . 

6.4.2 The tape drives shall be able to read and write, with read-af ter-wri te 
check. 

6.4.3 The tape drives shall accept hal f-inch tape, recorded at I6OO BPI, 
nine-track tape. 

6.4.4 The tape drives shall operate at speeds of 20-25 IPS minimum. 

• 6.5 Line Printer 

6.5.1 The line printer shall include any necessary controller. 

6.5.2 The line printer shall have 132 print positions. 

6.5.3 The line printer shall have print spacing of 10 characters per inch 
horizontal and six or eight lines per inch vertical, switch selectable. 

6.5.4 The line' printer shall be adjustable to accept paper or forms from 
four inches to 14-7/8 inches in size horizontal. 
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6. 5*5 The line printer shall have top-of-forms sensing. 

6.5.6 The line printer shall have a manual forms eject. 

6.5*7 The line printer shall have a pin-feed, continuous forms tractor feed. 

6.5.8 The line printer shall have programmed carriage control, 

6.5.9 The line printer shall have high-quality print on at least four-part 
paper. 

6.5.10 The line printer shall have a rated speed of not less than 300 lines 
per minute when printing full 1 32-character lines. 

6.5.11 The line printer shall have a standard ASCII 6A-character set, with 
an optional 96-charac'ter ASCI! set. 

6.5.12 (Optional) The train or chain shall be removable to change type fonts 
and character sets. 

6.6 Character Printer 

6.6.1 The character printer shall include any necessary controller. 

6.6.2 The character printer shall. have 132 print positions. 

6.6.3 The character printer shall have print spacing of 10 characters per 
inch horizontal and six or eight lines per inch vertical, switch- 
sel ectabje. 

6.6.4 The character printer shall have top-of-forms sensing. 

6.6.5 The character printer shall have a manual forms eject. 

6.6.6 The character printer shall have programmed carriage control 

6.6.7 The character printer shall be adjustable to accept paper from four 
Inches to 14-7/8 inches in size horizontally. 

6.6.8 The character printer shall have a pin-feed continuous forms tractor 
feed . ^ 

6.6.9 The character printer shall have high-quality print on at least four- 
part paper. 

6.6.10 The character printer shall have a rated speed of not less than 160 
characters per second when printing full 132-character lines. 

6.6.11 The character printer shall have a st;andard ASCII 64-pharacter set. 

6. 7 CRT Term; na Is 



6.7.1 The CRT terminal bid shall have a min imum d ispl ay capacity of 1,920 

characters with a screen display image of at least Zk displayable lines 
vertically and with 80 characters horizontal on each line. 



6.7-2 The terminal shall have at least a twelve-Inch diagonal screen. 

6.7.3 The terminal shall meef'all current and reasonable future OSHA and 
other pertinent regulatory agency requi rements regarding radiation 
electromagnetic interference (EMI), noise level, user fatigue, etc. 

6.7.4 The terminal's display intensity shall be variable by the operator 
via a manual brightness and/or contrast control knob. 

6.7.5 The terminal's display shall provide a nondestructable single- 
character cursor that is both addressable and readable via programming. 

6.7.6 The terminal shall have a power on/off switch that "is user-accessible. 

6.7.7 The terminal shall have keys des ignatedcfor special functions in each 
system. 

6.7.8 The terminal's display shaT. provide for character or field blinking « 
or intensity control. 

6.7.9 The terminal shall be capable of automatically skipping the cursor 
to the next programmed tabulation stops. 

6.7.10 TheTenjiinal shall have computer-controlled protected/unprotected 
auto-skip feature. , --^ 

6.7.11 The tern^inal shall be capable of d'splaying both upper and lower 
case characters . 

6.7.12 The terminal shall have program control led bri ght/normal/dark intensity.' 

6.7.13 The terminar'^hall have the capability of allowing programming to er^se 
the entire screen at one time. 

6.7.14 The terminal shall have an audible alarm or bell. , J 

6.7.15 The terminal shall use American-Engl ish block-sty le Alphabet ic and 
numeric characters, with true descenders. ( 

6.7.16 The terminal's display resolution shall equal or exceed that obtainable 
with a dot matrix five dots wide by seven dots high. 

6.7.17 The terminal shall be RS-232C compatible wi th the C>U bid^ 

6.7.18 Each terminal shall be pi ug-to-pl ug compatible with any other CRT 
terminal bid, to allow terminals to be moved from site to site without 
hardware modification. 

6.7.19 The terminal shall operate properly at standard data transmission rates 
using standard serial asynchronous communications line protocpl . 

6.7.20 The terminal shall provide editing features which h\\o^ character insert/ 
delete, character display/erase, and selected character repeat. 
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6.7.21 The terminal shall have buffering of at least 1,920 characters before 
transmission to the. CPU, 

6.7.22 The terminal shall have an additional I/O port which wljl enable It to 
be Interfaced with a printer device. 

6.7.23 (Optional) Terminals other than the ones bM.shal] Interface with the 
system belng^bld. 

6.7.2^ (Optional) The ALA 192-character , extended 8-blt ASCII set shall be 
available on the terminal, which may be Interfaced to the system bid. 

6.8 Optical Scanners 

6.8.1 Hand-held scanners <^hall be bid, with flexible cords at least 42" in 
length unflexed or 6' flexed* 

6.8.2 The scanner shall be capable of reading standard Optical Character 
Recognition (OCR) labels, or, i ndustry-compat ib 1 e barcode labels. 

6.8.3 All necessary controllers, cables, and other hardware essential to 
connect the scanners to the CRT terminals shall be bid. 

,6'. 8. 4 The scanner shall emit an audible "beeper" tone when a label is read 
correctly. 

6.8- 5 The scanner shall be capable of checking digit read automatically. 

6.9 CRT Screen Printers 

6.9- \l The CRT screen printer shall be RS-232C connectable to the printer 
\ or I/O port of the CRT terminal bid. 

6.9.2^ The printer shall have 80 print positions. 

6.9.3. The printer shall have pin-feed, continuous forms tractor feed 
^ (adjustab le) . 

6.9.4 The printer shall have full standard ASCII character set, with upper 
\ and lower case^ 

6.9.5 The printer shall have six lines per inch vertical. 

6.9.6 The printer shall have a rated speed of not less that 30 cps when 
printing ful 1 80-character 1 ines . 

6.9.7 The printer shall have top-of-forms sensing. \ 

6.9.8 All necessary cabling to connect the printer to the CRT terminal shall 
be included. ' 

6.9.9 ^The printer shall have a manual line feed. 

^.9.10 (Optional) The printer shall have a buffer for a minimum of 1,920 
characters of data. 
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6 Jo Portable Terminals 

6*10.1 The portable terminal shall be capable of offline entry and storage 
of from 3,000 to 5,000 circulation transactions or Inventory records 

6.10.2 The portable terminal shall be capable of transmitting its data to 
the CPU from any standard terminal connector.. 

6.11 CoiTvnun I cations - ^ 



6.11.1 The communications control hardware shall be sufficient In capacity 
and configration to process the communications input and output out- 
1 ined in Secti on 1.4. * / " 

6.11.2 Vendors shall configure communications equipment which will best fit 
S their systems and which>will maximize communications efficiency and 

effectiveness while minimizing costs/ to the University of Houston. 

6.11.3 Rotary line interfaces shall be included to accomodate a minimum of 
five remote users to be using 1/0 ports simultaneously via djal-up 
faci 1 ities. 
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7. SYSTEM SOFTVARE SPECIFICATIONS 

(Vendors are reminded that they must respond to each specification In this 
section by indicating one of the following In the apjbropr I ate part of the 
Specification Response Form at the end of this document: YES (feature or 
function available): YES/D (feature or function available, but with minor 
differences noted); YES/F (feature or function wfll be available at date 
specified); and NO (feature or function not available). 

7.1 general 

7 11 All system software necessary to operate the computer system to perform 
the functions outlined and support the functions specified in Sections 
3 through 6 shall be supplied by the vendor. 

7.1.Z Future enhancements to the system software shall be made available to 
the Libraries as long as it uses the system bid. 

7.2 Operating System 

7.2.1 The system shall include a real-time, multi-user operating system. 

7.2.2 The operating system shall provide for the processing of jobs in _ 
accordance with established priorities by schedul i ng Jobs . over lapping 
jobs requiring- no external intervention, and issuing messages to the 
operator as needed. <- 

7.2.3 The operating system shall provide for the queing and dispatching of . 
I/O operations in or'der to provide concurrent multi-task I/O support. 

1.2 h The operating system' shall provide a means of coordinating transfer 
of control between programs or tasks after completion of external 
events, waiting on one program or task, starting another, and later 
restarting the first program or task without loss of program or task 
integrity. 

7.2.5 The operating system shall include error-handling routines which ^ 
allow one task to recover or abnormally terminate while other 
processing continues and assures that operator intervention is kept to 



a minimum. 



7.2.6 The operating system shall adjust to the addition of future vendor- 
compatible peripherol equipment with only minor software changes. ^ 

7.2.7 The operating system .hail provide for the receiving processing, and 
dispaEching of Lssages from remote CRT terminals and other devices. . 

7.2.8 The operating system shall be adequate to manage efficiently the 
operation of the mul ti -programmed conditions described in the work- • 
loads in Section 1 .5. 

7.2.9 The operating system shall allow concurrent operation of more than 
two tasks. 

7.2.10 The operating system shall provide for automatic scheduling and loading 
of programs into memory. 
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7.2.11 The operating system shall provide an interrupt-handl I ng program that 
coordinates transfer of control between programs after an Interrupt, 

7/2.12 The operating system shall support an overlay or subtask system which 
allows a program to be run in segments. ^ 

7,2.13 The operating system shall Include a bootstrap function that allows 
the operator to specify from the front panei or operator console 
the device to originate the operating system,. 

7-2. l4 The operating system shall provide a set of ^diagnostic routines, 

loadable from more than one type of external storage device, which 
will test all of the hardware units (Including CPU, main memory, 
magnetic tape drives, disk devices, and other peripherals) and which 
isolates faults down to the component level. 

7.2.15 The operating system shall protect data files, or parts of them, to 

f revent injury, update, deletion, and creation without proper author- 
ization, through the use of passwords and/or other security mechanisms. 

7-3 Data Base Integrity 

7.3.1 Programs shall be provided which perform backup of all system data 
files onto some removable magnetic storage media. 

7.3.2 Public Online Catalog, Circulation, and Acquisi tions system transactions 
which result in new data records, or in modification of any existing^ 
data records, shall be logged on an external storage medium (tape, disk, 
etc.) physically distinct from the devices holding the data bases 
being thus backed up. 

7.3.3 Procedures and programs shall be provided which enable recovery from 
hardware or software failure. 

7. ^ System Securi ty 

7.k.] All application data files shall be protected from unauthori zed access 
(inquiry, update, deletion, or creation as applicable to each piece^ 
of data), through the. use of passwords and/or other security mechanisns. 

7.4.2 All system files (programs, application data, operating system, etc.) 

shall be protected from unauthorized access (inquiry/read/copy actions, 
modification, deletion, etc.), through the use of passwords and/or 
other security mechanisms. , 

7.^4.3 Functions not authorized for use by the public shall not be accessible 
from terminals assigned to the Public Online Catalog. 

J.kA Entry ^ito all other functions except inquiry shall be impossible from 
the Public Online Catalog termi.nals, even through passwords. 

7.4.5 A method of preventing determination of user^s passwords shall be pro- 
vided. 
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7.^.6 The libraries shall be- able to sped fy' wh ich functions can be per- 
'formed at Individual terminals. 

l.k.l The libraries shall be able to change or delete passwords and to 
change functions authorized to passwords at will. 

J.S Text Editor ' 

7. 5,1 A text editor shall be provided on th6 system. 

7^5.2 The text editor shall be able to create records jn a data file or a 
high-level source program file. ' 

7.5.3 An operator shall be able to change records in a data file or a high 
level source program file. 

7.5.4 An operator shall be able to delete records in a data file or a i.igh 
level source program file. 

7.5.5 The text editor shall be operable from the operator's console and 
from other specific terminals. 

7'.5,6 A user shall be able to print text from data entered into the text 
editor. 
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8. DOCUMENTATION 



(Vendors are reminded that they must respond to each specification in this 
section by indicating one of the following in the appropriate part of the 
Specification Response Form at the end of this document: YES (feature or 
function available); YES/D (Feature or function avai.lable, but with minor 
differences noted); YES/F (feature or function will be available at date 
specified); and NO (feature or function not available). 

8.1 Hardware Manuals 

8J.1 Two complete sets of descriptive and operational manuals for each 

separate equipment model bid shall be prov i ded ^upon its installation. 

8.1.2 Schematic drawings for the CRT terminals and screen printers shall 
be provided upon installation. 

8.1.3 Modifications or enhancements to the manuals or completely revised 
manuals shall be provided to the. Librarres on a conti'nuing basis for 
the duration of. its contracts with the successful bidder. 

8.2 System Software Manuals 

8.2.1 Two compJete sets of descriptive and operational manuals for the 
operating system and data base management system (if appropriate) 
shall be provided upon software installation, 

8,2i.2 Two complete reference and programmer guides to the programming 
language used shall be provided upon software installation. 

8.2-3 Modifications or enhancements to the maauals or completely revised 

manuals shall be provided to the Libraries on a continuing basis for 
the duration of its pontratts with the successful bidder. 

8>3 Application Software Manuals 

8.3.1 A minimum of two complete sets of reference, training, and operational 
manuals for monitoring and operating the system on a day-to-day basis 
shall be provided upon system installation. 

8.3.2 A minimum of two complete sets of reference, training, and operations 
manuals for the Public Online Catalog, Circulation, and Acqu 1 5 1 t ions 
systems shall be provided upon system installation (additional copies 
may be requested) . 

8.3.3 Modifications or enhancements to manuals or completely revised manuals 
shall be provided to the Libraries on a continuing basis for the 
duration of its contracts with the successful bidder. 
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10. HARDWARE AND SOFTWARE MAINTENANCE 



(Vendors are reminded that they must respond to each specification in this 
section by indicating one of the following in the appropriate part of the 
Specification Response Form at the end of this document: YES (feature or 
function available); YES/D (feature or function available, but with minor 
differences noted); YES/F (feature or function will be available at date 
specified); and NO (feature or function not available). 

10.1 Hardware Maintenance 

10.1.1 All-expense, flat-rate remedial hardware maintenance for the equipment 
shall be provided at the equipment site Monday through Friday, 8:00 a.m. 
through midnight, Saturday, 9:00 a.m. through 6:00'p.m. , and Sunday, 
12:00 noon through 12:00 midnight (all CDT/CST) . 

10.1.2 Normal remedial maintenance contact by vendor maintenance personnel 
shall be guarenteed to be within two hours after notification of need, 
with remedial work begun within four hours after vendor contact, except 
in rare and unusual circumstances, through mutually agreed-upon con- 
tacting procedures. 

10.1.3 All-expense, flat-rate preventive hardware maintenance for the equip- 
ment shall be provided at the equipment site, at times mutually agreed 
upon by the libraries and the vendor (it is desired that prev.entive 
maintenance be performed outside normal operating hours of the 
libraries). 

lO.l.V An adequate supply of repair parts shall be maintained locally to 
rep,air a minimum of ZS% of all hardware failures during a calendar 
year. 

10.1.5 Repair parts to meet the remaining ]S% of hardware fai 1 ures shal 1 

be made available within twenty-four hours (continuous time;, except 
under rare and unusual circumstances. 

10.1.6 Records/reports of each remedial or preventive maintenance activity 
performed shall be maintained at the user site. 

10.1.7 Maintenance reports shall include as a minimum: (a) date and time^ 
notified; (b) date and time of arrival; (c) type and moael of machine • 
serviced; (d) -time spent for repair or service; (e) description of 
malfunction or service; (f) date and time equipment Was made operational; 
and (g) signature of both maintenance and library representatives. 

10.1.8 The vendor shall have a cost-free telephone number for hardware main- 
tenance cal Is . 
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10.2 Software Maintenance 

10.2.1 AU-expense, flat-rate maintenance of all system and application 

software shall be provided Monday through Friday, 8:00 a.m. through 
midnight, Saturday, 9:00 a.m. through 6:00 p.m., and Sunday, 12:00 
noon through 12:00 midnight (all times CDT/CST) . 

10-2.2 The vendor shall perform software maintenance by a dial-in arrangement 

10.2.3 The vendor shall provide a cost-free telephone number for software 
maintenance cal Is. 

10.2.4 The vendor shall systematically inform the libraries of on-going 
system software enhancements as they are developed and shall solicit 
library input when critical system changes are being contemplated, 
and stipulate cost to the libraries, if any, for software enhancements 

10.2.5 The vendor shall guarantee the right of the libraries to upgrade to a 
later-developed and improved system- 
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SURVEY RESULTS ON THE INTEGRATED LIBRARY INFORMATION SYSTEM 



I • System Functions , 
A, Chart , 

On the following chart, please indicate which functions you have automated or 
are now automating, intend to automate, or do not intend to automate as part of 
an integrated library information system (as defined in the coyer memorandum) . 

In the " Plan to Develop Function " column you should choose only one of the 
four possible choices for each .of the separately numbered functions listed on 
the chart^.(you may choose different options for each of the separately listed 
functions'or subfunctions) . Within this column, " local " development includes 
new software already developed or being developed at your library or in 
cooperation with other libraries. Do not include large network systems (see 
"Turnkey Systems" below). " Purchase software " includes systems where the 
library has purchased or intends to purchase software, but has or will locally 
mount or adapt those programs (e.g., NOT IS). " Turnkey systems " includes vendor 
systems (e.g., DataPhase., Geac) arid centralized large network or utility 
systems (e.g., OCLC, RLIN) where the vendor or utility provide all necessary 
hardware and software. " Not sure how " implies that your library does have 
definite plans 'to automate that function, but a course of action has not yet 
been selected. If possible, provide a written statement of which possibilities 
are under most active^ consideration. 

If you have no definite plans to automate a particular function, indicate 
this in the last column (" No present plans to developt function "). 

RESPONSE: n = 31. All totals do not equal 100% because of rounding. 
Responses of the subfunctions listed calculated as follows: 1 = 3.2%; 2 = 
6.5%; 3 = 9.7%; 4 = 12.9%; 5 = 16.1%; 6 = 19.4%; 7 = 22.6%; 8 = 25.8%; 9 = 
29.0%;a0 = 32.3%; 11 = 35.5%; 12 = 38.7%; 13 = 41.9%. Averages shown for 
the four main functio ns are based on the averages of the subfunctions as 
shown. 



Functions 


Have deve' 
as part o" 


oped/Plan to develop function 
' an integrated library system: 


No present 
plans for 
this ILIS 
function 


Local ly 


Purchase 
software 


Turnkey 
system 


Not 

sure how 


A. ACQUISITIONS (includes 
monographs & serials): 


33.8% 


5.6% 


25.3% 


25.8% 


10.6% 


1. Ordering 


. 32.3% 


6.5% 


29.0% 


22.6% 


9.7% 


1, Claiming 


32.3% 


^ 6.5% 


29.0% 


25.8% 


6.5% 


. 3. Serials Check-in 


29.0% 


' 3.2% 


19.4% 


35.5% - 


12.9% 


4. Inprocess control 


38.7% 


6.5% 


29.0% 


19.4% 


6.5% 


5. Binding control 


25.8% 


3.2% 


1 

16.1% 


29.0% 


25.8% 


6. Accounting 


38.7% 


6.5% 


25.8% 


22.6% 


6.5% ' 


7. Vendor control 


32.3% 


6.5% 


29.0% 


25.8% 


6.5% 



LIST OF FUNCTIONS CONTINUED ON THE NEXT PAGE 
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r U f IL L 1 Ullb 


Have developed/Plan • 
3S part of an integr 


ated libr 


1 function 
ary system: 


No Dresent 
plans for 
this ILIS 
function 


Loca 1 ly 


rurcnasc 
SOT uwarc 


Turnkey 
system 


Not 

Sure how 


B. CATALOGING (maintenance) 




8.6% 


37.6% 


14.0% 


11.9% 


1 Bib! ioaraohic data 


LC.O/o 


0 7^ 


41.9% 


12.9% 


12.9% 


2 Authori tv rnntrni 




0 • 0 A7 


35.5% 


16.1% 


12.9% 


3. Holdinas data 




Q 7^ 
^ • 1 h 


35.5% 


9.7% 


9.7% 














C. CIRCULATION 


27.9% 


9.7% 


35 ..5% 


20.5% 


6.6% 


1. Charge-out/Charge ir 
of materials 


29.0% 


9.7% 


35.5% 


19.4% 


6.5% 


2. Recall and billing 


29.0% 


9.7% 


35.5% 


19.4% 


6.5% 


3. Reserve lists 
& charge-out 


25.8%' 


9.7% 


35.5% 


22.6% 


6.5% 














D. ACCESS (ONLINE CATAl^OG) 


33.9% 


8.9% 


27.4% 


19.4% 


10.5% 


1. Traditional 

c o 3 v*^ h T n n 
bca 1 Lil 1 liy 

mechanisms' 
(author, 
title, etc. ) 


32.3% 


12.9^« 


35 5% 

\J>J • >J to 


12 9% 


6.5% 


2. Enhanced search 

(e.g. > keyword. 
Boolean operators) 


29.0% 


9.7% 


32 .3% 




6.5% . 


3. Access to 
non-catal og 
data, e.g. , 
inprocess, holdings, 
circulation 


41.9% 


6.5% 


25.8% 


12.9% 


12.9% 


4. Order Commands, 
e.g. , request 
printouts, document 
delivery; holds 


32.3% 


6.5% 


16.1% 


29.0% 


16.1% 














AVERAGE OF ALL CATEGORIES 


31.1% 


8.2% 


-31.5% 


19.9% 


9.9% 
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8. If you are planning to (or did) implement the^system in stages, what is 
(was) the priority order for implementation? '* ^ 

RESULTS: n. = 26. 9.8% of survey respondents did not respond to this 
question. 6.4% were not planning to implement the system' in stages. 
The remaining 83.8% wer.e Implementing the system in stages. 
Responses were weighted, and the following rank order indicates. the 
weight assigned. 



Stage 


Category 


Weight 


1 


Cataloging (Maintenance) 


78 


2 


Circulation 


73 


3 


Acpess (online catalog) 


54 


4 


Acquisitions 


51 



Planning Responsibilities . 

{ 

1. Does (or did) your library have an established committee for the 
oversight of the development of an integrated library infori?atioi« 
system? 

RESULTS: 6.4% of the survey respondents did not respond to this 
question. Percentages shown are of those who responded to this 
question (n = 29). ' 

55.2% Yes [n = 16] 

44.8% No [n = 13] 

2. Is (was) this committee separate from the regular administrative group 
of the library (e.g., department heads group, assistant university 
librarians group, etc.)? 

RESULTS: 51.6% of the survey respondents did not respond to this 
question (6.4% did not respond to question 1 above, and the 
remaining 45.2% responded "no" to that question). Percentages shown 
are of those who responded to this question (n =16). 

94.0% Yes [n = 15] 

6.0% No [n = 1] 
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3. What position has the primary responsibility and authority for the 
development of the integrated library information system? 

RESULTS: 16.1% of the survey respondents did not respond to this 
question. The responses given below are in rank order, (n = 26) 



27.0% 

15. n 

15.4% 

11.5^ 
11.5% 
7.7% 

7.7% 



Assistant University Librarian for Technical Services [n=7] 

University Librarian (Director/Dean of Libraries) [n=43 

Assistant University Librarian for Technical Services 
. and Automation- [n=4] ^ 



Head of Library Systems 
Other position En=3] 



[n=3] 



Assistant University Librarian/Coordinator of Automation 
Cn=2] 

Assistant University Librarian for Administrative Services 
[n=2] ^ ' ^ 



3.8% No position primarily responsible [n=l] 
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III, Data Available , 

<♦ N ^ 

A, For the retrospective conversion (recon) of the bibliographic records 
for your library that are not now represented in machine-readable form, 
did you or do you intend to do: 

RESULTS: Two results reported. Column 1 is of all respondents (n = 
31). Column 2 is only of those libraries' that do have definite 
plans^ 



1 


2 


54.8% 


68.8% 


19.4% 


24.0% 


3.2% 


4.0% 


3.2% 


4.0% 


19.4% 





"Full" recon (75-100% of the collection) 
Partial" recon (25-75% of the collection) 
"Minimal" recon (less than 10-25%) 
Little recon (0-10% of the collection) 
No definite plans at this time for recon 



n = 17 

n = 6 

n = 1 

n = 1 

n = 6 



B. Will converted records have: 



RESULTS: Two results reported. Column 1 is of all respondents (n = 
31). Column 2 is only of those libraries that do have definite 
plans. " • 



1 

6.5% 
74.1% 
19.4% 



8.0% Short record only 
92.0%' Full bibliographic information 
No definite plans 



n = 2 
n = 23 
n = . 5 
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IV. What a^e the primary factors that your library has used or is using to 
justify (to the university, funding agencies, etc.) the development of an 
integrated library information system?. Rank the top five of the 
foil owing items in order of importance. 

RESULTS: Results were weighted, with n = 412. Factors are listed in 
rank order, along with the weighted percentage of respondents who 
considered this fafctor to be important. 



Rank Percent 



2 
3 

4 

5 

6 

6 
7 

8 
9 
9 

10 
10 

11 
11 

12 
12 

13 



18.2% 

17.7% 
14.3% 

9.0% 

8.3% 

5.9% 

5.9% 
5.6% 

3.9% 
2.4% 
2.4% 
1.5% 
1.5% 

0.9% 
0.9% 

0.7% 
0.7% 

0.2% 



Increase the amount of information available to 
the public 

The ability to provide distributed access to data 
Improved access tS data (via ke^'words, Boolean 

operators, etc.) 
To increase staff productivity by simplifying file 

maintenance 
Centralization of all library data for the 

public ~ „ 
To provide better management data, reports arid 

statistics' ^ 
To provide more up-to-date information 
To reduce the number of staff or avoid any increase 

in staff 

To avoid redundant keying of da^ta 
Provide for more accurate record-keeping 
Improved service 

A perception that automation will reduce costs 
To simplify systems for internal record-keeping and 
control 

Improved collection management information 
Automated authority control and ability to do 

"gl6ba,l updates" 
Networking capabilities 

The provision to automate functions now done in a 
manual mode 

The reduction in the amount of paper generated 



Factors perceived to inhibit implementation of an integrated library 
information, system. Rank the top five of the following items in order 
of importance, " " 

RESULTS- ResuK.s were weighted, with n = 341. Factors are listed .in 
rank order, alonn ^.h the weighted percentage of respondents who 
considered this f or to be important. 
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Rank Percent 



1 

2 

3. 

4' 

5 



23 
21 
17 
9 



4% 
7% 

4% 
7.3% 



Lack' of funds to carry out plans 
Cost to develop (hardware and softwares- 
Cost to maintain and operate 
Lack 'Of staff to develop and implement system 
Problems too advanced for current automation 
capabi 1 ittes 
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V. Factors per'ceived to inhibit implementation of an integrated library 
. information system. (CONTINUED) , . 

'Difficulty of the planning task 
Lack of university administration support 
System not perceived as saving money 
Staff resistance or lack of support 
Question tht advisability of an ILIS 
Missing linkage between experts in automation and 
librarians 

Problems with univers/ty computational center 
Lack of data about the needs and behavior of users 
Faculty resistance or lack of support 
Difficulty in maintaining system . 



6 


5.6% 


7 


4.4% 


8 


3.2% 


9 


2.1% 


10 


1.4% 


11 


1.2% 


11 


i.2% 


12 


0.9% 


13 


0.6% 


14 


0.3% 



VI. System Funding . • ' " 

How^was or will the system be funded? 

RESULTS: If there was<iiiore than one source per category, the approximate 
percentage of costs dlfofiated, or to be allocated, from each source, was 
shown. If dif.ferent functions [acquisitions, cataloging, circulation, 
online catalog) were funded from different sources, this was also 
indicated. 

The percentages are an average of the ,29 .libraries that responded to 
this question. The percentages show the percentage of the cost that will 
come from each source, e.g., under "Development/Analysis Costs", 54.0% of 
those costs will come from the regular 1 i bra ry, budget, and under "AVERAGE" 
' 42.4% of all costs will come from the regular library budget. 
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^Source of funding 


Devel opment/ 
•Analysis Costs 


. Hardware 
Costs 


Software 
Costs 


Maintenance 
Costs 


AVERAGE 


Regular library 
budget 


54.0% 


25.7% 


22.8% 


67.3% 


42.4% 


Special university 
allocation 


18.9% 


46.7% . 


41.6^ 


22.7% 


32.5% 


— r 

Outside grant . 


10.2%, 


6.7% 


10.2% 


1.7% 


7.2% , 


Private Dqriation 


1.9% 


7.6% 


6.5% 


0.0% 


4.0% 


Library/ 

university 

endowment 


3.1% 


8.2% 


7.7% 


3.3% 


5.6% 


No funds. Work 
done by^niv. 
^computation 
center 


11.9% 


5.1% 


11.2% 


5.0% 


8.3% 
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VII. Computer Support . 

A. Are computing facilities now provided or will they be provided 
primarily from: 

RESULTS: n = 32 (multiple responses permitted) 

21, The central campus computed' [n = 7] 

3.1% A non-central campus computer tnat the library will - 
• ' share with another university department [n = 1] 

/' 

68,8% A dedicated library computer, [n = 22] 

Multiple responses permitted. Of the 68.8%, the 
breakdown is as follows: 

18.2% Mainframe, [n =^4]. Models sppcified: 1 - 

Honeywell L66 DPS/B; -1 - Magnuson M80/43; 1 

- CDC Omega 480, Model 3; 1 - unspecified. 

. 72.7% Mi nicompu ter, [n = 16]. Models specified: 4 

- unspecified; 3 - GL^C 8000 (with multiple 
processors); 2 - Tandem NonStop; 2 - IBM 
Series I;. 2 - VAX 11/750; 1 - IBM 4331; 1 - 
Hewlett-Packard 3000; 1 - Data General 
Eclipse S/14'a; 

0.0% Microcomputer . 

6.2% Not yet determined. [n = 2j 

B. What type of system is jDr will be used for backup should the computer 
fail? ' . . ^ 



RESULTS: n - 41 (rpultiple- responses pei^mitted) 
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36.6% 


Con.puter Output Microform (COM) 


[n = 


15] 


34.1% 


Redundanl computer systems 


[n = 


14] 


' 12.2^ 


Manual -Piles 


[n = 


5j 


7.3% 


No backLO system intended 


[n = 


3] 


9.S% 


Not yet determined 


[n = 


4] 
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VIII. Consultants 

Have you used (or do you intend to use) outside consultants in the 
' planning, development, or selection of the integrated library information 
system? If so, for what purpose? 

RESULTS: n = 29 institutions responding. Under "we have used/intend to 
use/may use a consultant", multiple responses were permitted. 
Percentages shown in that category are of all institutions responding, 

\ 

55.2% We have not used/have no present plans to use outside 
consultants [n =16] 

44.8% We have used/intend to use/may use a consultant for: [n = 13] 

15.0% assistance and direction in the decision-making process 

15.0% analysis of prepared specifications 

15.0% develop specifications for hardware (computer, etc.) 

10.0% help with implementation of the system (prepare training 
materials, train staff, etc.) 

7.5% development of specifications/request-for-proposal 
' 7.5% develop cost figures 

' 7.5% choose a vendor turnkey system or software package 

; 7.5% choose necessary hardware (computer, terminals, etc.) 

i 

7.5% evaluate networking capabilities/possibilities 
• 2.5% contract programming 
• 2.5% system maintenance 
! 2.5% administrative review 



/t-; survey results prepared by Arnold Hirshon 
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LIST OF INSTITUTIONS SURVEYED 



Bostoa University * 
Brown University 
Cornell University * 
Dartmouth College , 
Duke University 
Emory University 
Florida State University 
Johfis Hopkins University * 
Nev) York University 
Noi^thwestern University 
Ohio State University 
P^/insylvania State University 
Purdue University 

State University of New York at Albany 
Syracuse University 
University of California at Berkeley 
University of California at Los Angeles 
' University of California at Santa Barbara 
University of Chicago * - / 

.Un.i varsity of Georgia 
University of Houston 
University of Illinois 
University of Iowa 
University of Minnesota 
University of Missouri (Columbia) 
University of Nebraska 
University of New Mexico 
University of Notre Dame 
University of Oregon 
University of Pittsburgh 
University of Tennessee 
University of Texas (Austin) 
University of Wisconsin 
University of Washington 

Virginia Polytechnical Institute and State University 
* - not included j'n final results (no response). 
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